Load rate determination method of processor, vehicle and storage medium

Abstract

The embodiment of the invention provides a processor load rate determination method, a vehicle and a storage medium, and the method comprises the steps: obtaining a plurality of operation moments when a central processing unit of a controller operates a first operation task in the operation process of an operation system in the controller; based on the multiple operation moments, at least one operation time period when the central processing unit operates at least one second operation task is determined, and under the condition that the second operation task operates, the priority of the second operation task is larger than that of the first operation task; and determining the load rate of the central processing unit based on the at least one operation time period. The technical problem that the performance detection efficiency of the operating system is low is solved.

Description

Technical Field

[0001] This application relates to the field of system detection technology, and more specifically, to a method for determining processor load rate, a vehicle, and a storage medium. Background Technology

[0002] Currently, there is no complete CPU performance testing solution for some lightweight operating systems applicable to microcontroller unit (MCU) chips.

[0003] In related technologies, detecting the performance of a running system on an MCU requires the use of MCU chip debugging tools. For example, the frequency of flash memory address access can be used to roughly estimate the current system's operating status. However, this method requires connecting to hardware debugging tools and developing debugging software by a third-party organization. Therefore, this method suffers from the technical problem of low efficiency in operating system performance detection.

[0004] There is currently no good solution to the above problems. Summary of the Invention

[0005] This application provides a method for determining processor load rate, a vehicle, and a storage medium to at least address the technical problem of low performance detection efficiency of the operating system.

[0006] According to one aspect of the embodiments of this application, a method for determining the load rate of a processor is provided. The method may include: during the operation of an operating system in a controller, acquiring multiple running times of the controller's central processing unit (CPU) running a first running task; based on the multiple running times, determining at least one running segment of the CPU running at least one second running task, wherein, when the second running task is running, the priority of the second running task is greater than the priority of the first running task; and determining the load rate of the CPU based on the at least one running segment.

[0007] Furthermore, determining the CPU load rate based on at least one runtime segment includes: determining the computation cycle based on at least one runtime cycle of at least one second running task; determining the total runtime segment based on at least one runtime segment; and converting the total runtime segment using the computation cycle to obtain the load rate.

[0008] Furthermore, determining the calculation cycle based on at least one running cycle of at least one second running task includes: determining the least common multiple of the at least one running cycle as the calculation cycle.

[0009] Furthermore, based on at least one runtime segment, the total runtime segment is determined, including: the sum of the at least one runtime segment is determined as the total runtime segment.

[0010] Furthermore, the total runtime is converted using the calculation cycle to obtain the load rate, including: determining the load rate as the quotient between the total runtime and the calculation cycle.

[0011] Furthermore, during the operation of the operating system in the controller, obtaining multiple runtime moments of the controller's central processing unit running the first running task includes: stopping the first running task in response to starting the second running task and obtaining the end time of the first running task; obtaining the start time of the first running task in response to ending the second running task and starting the first running task, wherein the multiple runtime moments include the start time and the end time; and determining at least one runtime segment of the central processing unit running at least one second running task based on the multiple runtime moments, including: determining the difference between the end time and the start time as the second runtime segment of the second running task.

[0012] Furthermore, the method may further include: determining the actual number of runs and the theoretical number of runs for at least one periodic task in at least one second running task; comparing the actual number of runs and the theoretical number of runs to obtain a comparison result, wherein the comparison result is used to characterize the magnitude relationship between the actual number of runs and the theoretical number of runs; and determining the running state of the periodic task based on the comparison result, wherein the running state is used to characterize the delay of the periodic task.

[0013] Furthermore, the method may also include: in response to a delay in the operation of the second running task, determining the actual running time and theoretical running time of the second running task; and based on the actual running time and the theoretical running time, determining the cause of the delay in the second running task.

[0014] According to another aspect of the embodiments of this application, a processor load rate determination apparatus is also provided. The apparatus may include: an acquisition unit, configured to acquire multiple running times of the central processing unit (CPU) of the controller running a first running task during the operation of the operating system in the controller; a first determination unit, configured to determine at least one running segment of the CPU running at least one second running task based on the multiple running times, wherein, when the second running task is running, the priority of the second running task is greater than the priority of the first running task; and a second determination unit, configured to determine the CPU load rate based on the at least one running segment.

[0015] According to another aspect of the embodiments of this application, a vehicle is also provided, including: a memory storing an executable program; and a processor for running the program, wherein the program executes the methods of various embodiments of this application when it runs.

[0016] According to another aspect of the embodiments of this application, a computer-readable storage medium is also provided, the computer-readable storage medium including a stored executable program, wherein, when the executable program is running, it controls the device where the computer-readable storage medium is located to run the methods of various embodiments of this application.

[0017] According to another aspect of the embodiments of this application, a computer program product is also provided, including a computer program that implements the methods of various embodiments of this application when run by a processor.

[0018] According to another aspect of the embodiments of this application, a computer program product is also provided, including a non-volatile computer-readable storage medium storing a computer program, which is executed by a processor to implement the methods in various embodiments of this application.

[0019] According to another aspect of the embodiments of this application, a computer program is also provided, which is executed by a processor to implement the methods of the various embodiments of this application.

[0020] In this embodiment, during the operation of the operating system in the controller, multiple runtime moments of the controller's central processing unit (CPU) running a first running task are acquired. Based on these multiple runtime moments, at least one runtime segment in which the CPU runs at least one second running task is determined, wherein, when the second running task is running, the priority of the second running task is higher than the priority of the first running task. Based on the at least one runtime segment, the CPU load rate is determined. That is, in this application, a first running task is constructed, which can be an idle task. By monitoring multiple runtime moments of the first running task, the runtime of the second running task is determined. Based on the second runtime, the CPU load rate in the operating system can be determined, thereby achieving the technical effect of improving the detection performance of the operating system and solving the technical problem of low performance detection efficiency of the operating system. Attached Figure Description

[0021] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:

[0022] Figure 1 This is a flowchart of a method for determining the load rate of a processor according to an embodiment of this application;

[0023] Figure 2 This is a schematic diagram illustrating a load rate operation according to an embodiment of this application;

[0024] Figure 3This is a schematic diagram illustrating the operation of events with different priorities according to an embodiment of this application;

[0025] Figure 4 This is a schematic diagram illustrating the operation of a task according to an embodiment of this application;

[0026] Figure 5 This is a schematic diagram of a runtime segment according to an embodiment of this application;

[0027] Figure 6 This is a schematic diagram of a processor load rate determination device according to an embodiment of this application. Detailed Implementation

[0028] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort should fall within the scope of protection of the present application.

[0029] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0030] According to an embodiment of this application, a method embodiment for determining the load rate of a processor is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0031] Currently, there is no complete CPU performance testing solution for some lightweight operating systems suitable for microcontroller chips. To test the performance of the currently running system on an MCU, MCU chip debugging tools are needed. For example, the frequency of memory address accesses can be used to roughly infer the current system's operating status.

[0032] In related technologies, the common approach is to use MCU debugging tools to query the frequency of flash address access, and then use the flash address in conjunction with the compiled file to deduce the corresponding software execution function, thus calculating the function call frequency. While this method shows which functions are being executed, the current function may be subject to deep secondary calls, with multiple tasks calling the same function. Therefore, this method cannot reflect the task load. Furthermore, this method requires a hardware debugging tool and software development by a third-party organization. Additionally, the performance of each toolchain varies, leading to poor compatibility. External debugging tools access the MCU's flash, and the CPU also accesses the flash. This creates a competition relationship, so the impact of external debugging tools on CPU operation needs to be evaluated. External debugging tools are used for online debugging; in real-world testing phases, external debugging tools are not permitted, thus limiting their application scenarios. Therefore, the above method cannot calculate CPU load, cannot pinpoint the cause of system task blocking, and suffers from the technical problem of low operating system performance detection efficiency.

[0033] In this embodiment, a first running task (e.g., an idle task) is constructed. By monitoring multiple running times of the first running task, the running time of the second running task is determined. Based on the second running time, the load rate of the central processing unit in the operating system can be determined, thereby achieving the technical effect of improving the detection performance of the operating system and solving the technical problem of low performance detection efficiency of the operating system.

[0034] Optionally, the above method can solve the problem of the MCU OS system being unable to calculate CPU load and locate the cause of system task blocking. It further resolves a series of problems caused by data latency and frame loss due to high system load. It provides a method for evaluating system operation without debugging tools, offering improved real-time performance and accuracy compared to third-party debugging tools. Furthermore, the above method can quickly locate the cause of data frame loss under high load conditions, providing a technical solution for CPU operation monitoring even when the MCU is offline.

[0035] This embodiment provides a method for determining the load rate of a processor. Figure 1 This is a flowchart of a processor load rate determination method according to an embodiment of this application. Figure 1 As shown, the method may include the following steps.

[0036] Step S102: During the operation of the operating system in the controller, obtain multiple running times of the controller's central processing unit running the first running task.

[0037] In the technical solution provided in step S102 of this application, the controller can be a microcontroller in a vehicle, which can integrate components such as a central processing unit (CPU), memory, input / output interface, and clock unit, and can run an operating system (OS). The operating system can be a running system that manages and schedules the hardware resources of the MCU, such as memory, CPU time, and peripheral interfaces. It can control tasks or processes waiting to run in the CPU and can schedule tasks according to task priority and priority strategies (such as priority preemption). The central processing unit can run the corresponding running tasks according to the instructions of the operating system. The first running task can be a pre-built idle task. For the MCU OS system, the first running task can refer to the task that the OS runs when at least one functional task (i.e., the second running task) is not running.

[0038] Optionally, CPU idle load rate refers to the proportion of idle tasks within a certain period of time. Therefore, in order to determine the CPU load rate, in this embodiment, an idle task (idle_task) is designed. This idle_task can be constructed according to the following requirements: it has the lowest priority in the entire OS system, lower than the second running task (e.g., isr or function_task); its type allows it to be preempted by a higher-priority second running task; and it cannot be terminated after it is started.

[0039] Optionally, because the OS needs to reschedule once the first running task terminates, adding overhead to the OS, this embodiment sets the idle_task to always be in an active "running" state and cannot terminate. Since the idle_task is always in a "running" state, it needs to be preemptible to avoid affecting the execution of other tasks.

[0040] Optionally, during the execution of the first running task, the running status of the first running task can be monitored to determine multiple running moments of the first running task. These running moments can include the start time and the end time of the running task, and can be used to determine the start time and end time of the first running task.

[0041] Optionally, within the controller, the operating system can manage the execution of multiple tasks (or processes) through priority scheduling policies to ensure the reasonable allocation of CPU resources.

[0042] Step S104: Based on multiple runtime times, determine at least one runtime segment in which the central processing unit runs at least one second running task, wherein, when the second running task is running, the priority of the second running task is greater than the priority of the first running task.

[0043] In the technical solution provided in step S104 of this application, the second running task can be a functional task, which may include, but is not limited to, a periodic task (basic_task), an event task (event_task), and an interrupt / exception task (isr). The runtime segment (t1_run) can be the task computation time for the second running task to run once.

[0044] Optionally, after determining multiple runtimes, calculations can be performed on the multiple runtimes to obtain at least one runtime segment of at least one second runtime task.

[0045] Optionally, the second running task has a higher priority than the first running task. Therefore, when the second running task is ready to execute, the currently executing lower-priority task (such as the first running task) can be interrupted. The execution time of the first running task is determined by comparing its execution time. For example, suppose the first running task is interrupted during a certain period, while a higher-priority second running task is running during that period. By analyzing the start and end times of the first running task, the actual execution segment of the second running task can be determined. This method eliminates the need to monitor the execution segment of the second running task; monitoring only the start and end times of the first running task is sufficient to determine its execution segment.

[0046] Step S106: Determine the load rate of the central processing unit based on at least one runtime period.

[0047] In the technical solution provided by step S106 of this application, the load rate of the central processing unit is obtained by converting at least one runtime period.

[0048] Optionally, after obtaining the runtime segment of the second running task, calculating the CPU load rate involves determining the proportion of time the CPU actually uses to execute the task within a specific time window.

[0049] Optionally, the operation of an OS can include three phases: "startup," "running," and "stopping," with software functions concentrated in the "running" phase. As more and more features are developed for a product, at some point during the OS's running phase, multiple functions may overlap, causing a sudden increase in OS load. Functions that cannot secure CPU resources cannot run in a timely manner. The two main carriers of the OS's "running" phase are "tasks" and "ISRs," with multiple functions running within them. First, ISRs have a higher priority than tasks. Furthermore, tasks may compete with each other; in any OS system, when competition occurs, the OS will prioritize scheduling the higher-priority task.

[0050] Considering the above reasons, in this embodiment, the tasks of the MCU system are constructed by dividing them into a first running task and a second running task. The second running task can be a task that performs a function, referred to as a function_task. The first running task can be a task that does not perform a function, referred to as an idle_task. If the first running task runs within a certain time period, it means that the CPU has spare capacity; if the first running task does not run, it means that the CPU is already at full load, which may lead to the risk of system frame drops.

[0051] Figure 2 This is a schematic diagram illustrating a load rate operation according to an embodiment of this application. For example... Figure 2 As shown, the CPU can run a first task and a second task, where the second task may include (function_task and isr). The runtime segment and computation cycle of the second task can be determined. Based on the runtime segment and computation cycle, the CPU load rate during the current time period can be determined.

[0052] CPU load (CPU_load) = Sum of at least one runtime (T_run) / Computation cycles (T_cycle) 100%

[0053] The runtime segment of the first running task can be the CPU's idle period.

[0054] Alternatively, the fact that an idle task runs does not guarantee that the operating system is free from the risk of data loss. This is because function tasks can also block each other. If multiple function tasks need to acquire OS resources at a given time, lower-priority tasks may be blocked by higher-priority tasks, leading to data loss as the lower-priority tasks cannot run. Figure 3 This is a schematic diagram illustrating the operation of events with different priorities according to an embodiment of this application, such as... Figure 3As shown, this can include 5ms tasks and 10ms tasks. Figure 3 As shown, the 5ms task should run at 5ms, 10ms, 15ms, 20ms, and 20+t_ms respectively. The 10ms task should run at 10ms, 20ms, etc. The fourth 5ms task failed to run in time because it was preempted by a higher-priority 10ms task. If the 10ms task depends on an event in the 5ms task, then that event within the 10ms task will not be executed. Therefore, in this embodiment, the scenario of operating system data loss can be condensed into two main categories: monitoring idle_task load rate and monitoring function_task mutual blocking. Moreover, these two categories can be collected and analyzed in real time through software, and the collected and analyzed data is finally stored in the log system. When a problem occurs, the logs at the fault scene can be analyzed.

[0055] Optionally, this embodiment uses the first running task to determine the CPU's idle period and working period (i.e., the running period), thereby determining the CPU's corresponding load rate, thus achieving the technical effect of improving the efficiency of load rate determination.

[0056] For example, by collecting logs, multiple running times of the first running task can be determined. By converting the multiple running times, the running segments of the second running task within at least one cycle can be determined, thus obtaining at least one running segment of the second running task. Based on at least one running segment of the second running task, the load rate of the central processing unit can be determined.

[0057] The above approach allows for real-time monitoring and analysis of the controller's CPU resource usage. By monitoring CPU load, resource shortages or overloads can be detected promptly, enabling measures to optimize task scheduling and prevent system crashes or data loss. For tasks with fixed cycles, if their execution time exceeds expectations, it can be analyzed whether the issue stems from the task's code efficiency or frequent interruptions by higher-priority tasks. This facilitates task optimization, reduces unnecessary interruptions, and improves overall execution efficiency. When system performance degrades or exhibits abnormal behavior, analyzing task runtimes and load rates accurately identifies the culprit. This provides robust data support for debugging and fault prevention. During system design, CPU resources can be rationally planned based on task priorities and expected execution times, ensuring critical tasks receive sufficient CPU time while preventing excessive preemption of low-priority tasks. For real-time systems, ensuring the timely execution of time-sensitive tasks (such as control tasks) is crucial. Precise load rate monitoring ensures that the system meets real-time requirements even under high load conditions.

[0058] Optionally, in embedded systems or real-time operating systems, when the CPU of a controller (such as a microcontroller MCU) is running multiple tasks, the execution order of the tasks can be determined through priority scheduling. Multiple execution times of the CPU's tasks can be obtained, and the CPU load rate can be determined based on these execution times.

[0059] In summary, this embodiment achieves precise monitoring of CPU resource usage by meticulously measuring and analyzing the time taken for the CPU to run tasks of different priorities in the controller, thereby improving the system's real-time performance, stability, and fault diagnosis capabilities. This is a highly valuable performance optimization and fault prevention measure for embedded systems and real-time control applications.

[0060] Through steps S102 to S106 above, during the operation of the operating system in the controller, multiple runtime moments of the controller's central processing unit (CPU) running the first running task are obtained; based on the multiple runtime moments, at least one runtime segment of the CPU running at least one second running task is determined, wherein, when the second running task is running, the priority of the second running task is higher than the priority of the first running task; based on the at least one runtime segment, the CPU load rate is determined. That is, in this application, an idle task (i.e., the first running task) is constructed, and by monitoring multiple runtime moments of the first running task, the runtime of the second running task is determined. Based on the second runtime, the CPU load rate in the operating system can be determined, thereby achieving the technical effect of improving the detection performance of the operating system and solving the technical problem of low performance detection efficiency of the operating system.

[0061] The above-mentioned method of this application will be further described below.

[0062] As an optional implementation, step S106, determining the load rate of the central processing unit based on at least one runtime segment, includes: determining the computation cycle based on at least one runtime cycle of at least one second running task; determining the total runtime segment based on at least one runtime segment; and converting the total runtime segment using the computation cycle to obtain the load rate.

[0063] In this embodiment, the aforementioned computation cycle (t_cycle) may include the execution time of at least one second running task. The aforementioned total runtime (T_functiontask) may be the runtime of multiple second running tasks.

[0064] Optionally, the computation period is determined based on at least one runtime of at least one second running task. The total runtime can be determined based on at least one runtime segment of at least one second running task. The load rate can be obtained by converting the total runtime using the computation period.

[0065] Optionally, the computation period is determined based on at least one running cycle of at least one second running task (i.e., a high-priority task), which can include the maximum running time of at least one second running task to ensure that the load rate calculation can fully reflect the system's performance status within this time window. For example, if there is a high-priority periodic task TaskHigh with a period of 10ms, then the computation period should be at least 10ms to ensure that TaskHigh can run at least once in any computation period.

[0066] Optionally, in order to monitor the system status more accurately, the calculation period can be selected as the least common multiple of at least one periodic task or an integer multiple thereof, so as to ensure that all periodic tasks run at least once within the calculation period.

[0067] Optionally, the total runtime refers to the total actual running time of at least one monitored task (including the first and second running tasks) within the computation cycle. This is obtained by accumulating at least one runtime (i.e., the actual running time of each task). For example, at least one runtime could refer to the period during which a low-priority task is preempted and cannot run while a high-priority task is running, as well as the running time of the high-priority task itself.

[0068] For example, within a 20ms computation cycle, Task 5ms (the first task) should run 4 times, but it actually runs 3 times. Task 10ms (the second, higher priority task) does run 2 times, with actual runtimes of 2ms and 3ms respectively. Additionally, Idle_Task runs 2 times within this cycle, for a total runtime of 5ms. Therefore, the total runtime within this computation cycle is: Task 5ms actual runtime: 3 × 5ms = 15ms; Task 10ms actual runtime: 2ms + 3ms = 5ms; Idle_Task actual runtime: 5ms (this reflects CPU idle time).

[0069] Optionally, the load rate mentioned above refers to the ratio of the time the CPU spends executing effective tasks to the total time of that time window within a specific time period. Converting the total runtime using computation cycles is to obtain a standardized load rate value, facilitating comparison and analysis across cycles.

[0070] By following the steps above, we can not only understand the CPU's performance under high load, but also monitor system performance in real time through dynamic changes in load rate, providing a basis for preventing issues such as data loss and system latency. Furthermore, this method eliminates the need for external debugging tools, reducing operational complexity and enhancing the independence and practicality of the test system. It is particularly useful in situations where external debugging tools are unavailable, such as in real-vehicle testing or actual product operation, enabling better evaluation and maintenance of system operational status.

[0071] This embodiment provides a software solution that eliminates the need for hardware debugging tools, reducing reliance on additional hardware and simplifying system testing and maintenance. Real-time monitoring allows for timely adjustments to task priorities or code optimization before system performance degrades, preventing data loss or delays caused by excessive load. Load rate calculation provides a quantitative standard for evaluating the rationality of the system design, aiding in performance prediction and resource planning in the early stages of development.

[0072] As an optional implementation, determining the calculation period based on at least one running cycle of at least one second running task includes: determining the least common multiple of the at least one running cycle as the calculation period.

[0073] In this embodiment, at least one running cycle of at least one second running task can be determined, and the least common multiple of the at least one running cycle is determined as the calculation cycle.

[0074] Optionally, the CPU computation cycle is not arbitrarily determined; it needs to cover the execution time of all tasks. Therefore, it needs to be the execution time of the task with the current longest execution cycle, or an integer multiple of the longest execution cycle. This ensures that all tasks have run, or at least that all tasks have completed one cycle. For example, this execution cycle can be the least common multiple of the tasks that have completed at least one cycle.

[0075] For example, the second running task may include: Task1, with a running cycle of 5ms; Task2, with a running cycle of 10ms; and Task3, with a running cycle of 20ms. The greatest common multiple of the multiple periodic tasks is selected as the calculation cycle, i.e., LCM(5ms, 10ms, 20ms) = 20ms, which means that the load rate can be calculated once every 20ms.

[0076] As an optional implementation, determining the total number of runtimes based on at least one runtime segment includes: determining the sum of the at least one runtime segment as the total runtime segment.

[0077] In this embodiment, the sum of at least one runtime within the calculation cycle can be determined as the total runtime.

[0078] Optionally, after determining the calculation period, if the function_task operation time t1_run, ..., tn_run is calculated n times within this period, then the current total function_task runtime T_functiontask = t1_run + t2_run + ... + tn_run.

[0079] For example, the second running tasks may include: Task1, with a running cycle of 5ms; Task2, with a running cycle of 10ms; and Task3, with a running cycle of 20ms. Based on these three running cycles, the computation cycle LCM(5ms, 10ms, 20ms) = 20ms is determined. The runtime segments of the three second running tasks are then determined. For Task1, Task2, and Task3, their runtime segments are calculated as T_task1_run, T_task2_run, and T_task3_run, respectively. Therefore, the total runtime segments T_functiontasks = T_task1_run + T_task2_run + T_task3_run. If Task1 runs multiple times within a computation cycle, then when calculating the total runtime segments, it is necessary to calculate the multiple runtime segments corresponding to Task1 within that computation cycle.

[0080] As an optional implementation method, the total runtime is converted using the calculation cycle to obtain the load rate, including: determining the load rate as the quotient between the total runtime and the calculation cycle.

[0081] In this embodiment, the quotient between the total runtime and the computation cycle can be determined as the load rate.

[0082] Alternatively, the load factor can be calculated using the following formula:

[0083] cpu_load=T_functiontask / t_cycle 100%

[0084] Here, `cpu_load` can be used to characterize the load rate. `T_functiontask` can be used to characterize the total runtime. `t_cycle` can be used to characterize the computation cycle.

[0085] Optionally, the task currently computing CPU load cannot be an idle task; it should be executed within the largest cycle task (the task within the same computing cycle).

[0086] For example, suppose that within a 20ms period, the actual running time (i.e., runtime segments) of each second running task are as follows: Task1's actual running time T_task1_run is 3ms (since it is a 5ms period task, this second running task runs 4 times within the 20ms period); Task2's actual running time T_task2_run is 6ms (a 10ms period task, runs 2 times in this computation cycle); Task3's actual running time T_task3_run is 15ms (a 20ms period task, runs 1 time in this computation cycle). The total runtime segments T_functiontasks = 3ms + 6ms + 15ms = 24ms. However, since no task can run for more than 20ms within a 20ms period, the actual T_functiontasks might be 19ms (if overlapping scheduling and interrupts are considered). Therefore, the load rate CPU_load = (19ms / 20ms) 100% = 95%. The calculation shows that within this 20ms calculation cycle, the CPU utilization reached 95%, meaning the CPU was running at almost full load, with only 5% of the time spent idle or executing idle tasks. This calculation result can reflect CPU usage in real time, helping developers understand whether the CPU is overloaded and make corresponding adjustments, such as optimizing task code, adjusting task priorities, or increasing hardware resources.

[0087] As an optional implementation, step S102, during the operation of the operating system in the controller, obtains multiple running times of the controller's central processing unit running the first running task, including: in response to starting the second running task, stopping the first running task and obtaining the running end time of the first running task; in response to ending the running of the second running task and starting the running of the first running task, obtaining the running start time of the first running task, wherein the multiple running times include the running start time and the running end time; based on the multiple running times, determining at least one running segment of the central processing unit running at least one second running task, including: determining the difference between the running end time and the running start time as the second running segment of the second running task.

[0088] In this embodiment, the runtime segment of the second running task can be calculated based on the running time of the first running task.

[0089] Optionally, the CPU can be controlled to execute the first running task before the second running task begins. If the second running task begins, the first running task can be stopped. The end time (t_out) of the first running task is obtained. The second running task is stopped after it completes, and then the first running task can begin running again. The start time (t_in) of the first running task can be obtained. The difference between the start time and the end time is determined, and this difference is used to define the runtime segment corresponding to this run of the second running task. In this way, at least one runtime segment corresponding to the second running task within this computation cycle can be determined.

[0090] Optionally, once the idle_task design is complete, the CPU load rate needs to be calculated. Figure 4 This is a schematic diagram illustrating the operation of a task according to an embodiment of this application. Figure 4 As shown, the end time (t_out) of the first running task (idle_task) and the start time (t_in) of the next run into idle_task are obtained. Then the runtime segment of the second running task (current function _task / isr) can be t1_run = t_out – t_in.

[0091] Optionally, the sources of t_out and t_in should not occupy OS resources, otherwise it will greatly affect CPU performance, which would be counterproductive. Therefore, in this embodiment, the hardware resources of the MCU are utilized, that is, the clock unit in the MCU is used to allocate a hardware clock to t_out and t_in through the MCU's hardware clock tree. Figure 5 This is a schematic diagram of a runtime segment according to an embodiment of this application. For example... Figure 5 As shown, one clock tick is 1 microsecond (µs). Therefore, the runtime segment corresponding to the current second running task is (t_in – t_out) µs. Because the hardware clock has a maximum integer overflow value, it restarts the upward counting mode after overflow. Figure 5 As shown, if the current runtime happens to cause an overflow, then the runtime calculation needs to be increased by the overflow value.

[0092] As an optional implementation, the method may further include: determining the actual number of runs and the theoretical number of runs for at least one periodic task in at least one second running task; comparing the actual number of runs and the theoretical number of runs to obtain a comparison result, wherein the comparison result is used to characterize the magnitude relationship between the actual number of runs and the theoretical number of runs; and determining the running state of the periodic task based on the comparison result, wherein the running state is used to characterize the delay of the periodic task.

[0093] In this embodiment, after calculating the load rate, the running status of the second running task can be further judged to determine the running status of the second running task.

[0094] Optionally, the characteristics of periodic tasks can be reasonably utilized, and the OS scheduling time can be referenced to reflect whether the current system is blocked. If a task is found to be blocked, data support is needed to analyze the cause of the blockage. For example, it can be determined whether the blockage is due to its own long execution time or preemption by other tasks. The cause of task blockage can be determined by comparing the number of runs or the execution time.

[0095] Optionally, by comparing the number of times tasks are run, the actual number of runs and the theoretical number of runs for at least one periodic task within at least one second running task can be determined. By comparing the actual number of runs and the theoretical number of runs, the running status of that periodic task can be determined. Here, the aforementioned periodic task (basic_task) can refer to a task within the second running task that has a fixed periodicity.

[0096] In this embodiment, the second running task can include three main categories: periodic tasks, event tasks, and interrupt tasks. The running counts of at least one periodic task within the at least one second running task can be compared to determine the running status of the periodic task. The actual running count of each basic_task can be counted to obtain the actual running count of the periodic task. Furthermore, the correspondence between these actual running counts can be used to reflect the blocking status of the periodic task.

[0097] For example, the current operating system has 5ms tasks and 10ms tasks, and of course, many other tasks. Within the t_cycle time, the number of times the 5ms task runs (N_5ms) will be twice the number of times the 10ms task runs (N_10ms). If N_5ms / 2 > N_10ms, it means the 10ms task is delayed; conversely, the 5ms task is delayed. Alternatively, the theoretical number of times the 5ms task should run within the cycle is twice. Therefore, if it actually runs only once, it can be determined that the actual number of runs is less than the theoretical number, and the 5ms task's running state is abnormal, classified as an abnormal running state.

[0098] Optionally, the above actual number of runs can be the number of times the OS triggers scheduling and runs the task, excluding scenarios where the task is interrupted and then runs again, or where the OS is activated but not scheduled to run.

[0099] Optionally, the actual number of runs can be compared with the theoretical number of runs to determine the running status of the periodic task. Alternatively, the actual number of runs can be compared with the actual number of runs of other periodic tasks to determine the running status of the periodic task. It should be noted that this is only an example and there are no specific restrictions on the method of determining the running status of the periodic task.

[0100] Optionally, in a real-time operating system (RTOS) environment, the controller's central processing unit (CPU) needs to efficiently manage and schedule multiple tasks to ensure system stability and performance. Here, "at least one second running task" refers to tasks with a higher priority than the first running task, which may include, but is not limited to, periodic tasks and interrupt service routines (ISRs). To evaluate the CPU's performance under high load, i.e., whether there is a risk of latency or data loss, the execution of periodic tasks can be monitored and analyzed through the following steps: First, the actual number of runs and the theoretical number of runs for the second running task can be determined. Here, "at least one periodic task" refers to tasks designed to run periodically, each with its preset period, such as 5ms, 10ms, etc. The theoretical number of runs is calculated based on the task's period and the observed time window, while the actual number of runs is the number of times the task is actually scheduled and run within this window.

[0101] For example, consider a task with a period of 10ms (called Task10ms). If the observation time window is 100ms, Task10ms should theoretically run 10 times. However, if the CPU load is high, causing Task10ms to be unable to be scheduled to run in some periods, the actual number of runs may be less than 10.

[0102] Furthermore, comparing the actual number of runs with the theoretical number of runs aims to check for any task scheduling delays or omissions. If the actual number of runs equals the theoretical number of runs, it indicates that all preset cycles within the observation window were fully utilized, and the task ran as expected. Conversely, if the actual number of runs is lower than the theoretical number of runs, this indicates a delay or omission, possibly due to preemption by higher-priority tasks or the task's own execution time exceeding the predetermined time slice, preventing the CPU from rescheduling the task at the start of the next cycle. Therefore, based on the comparison results, the running status of the periodic task can be determined.

[0103] Optionally, the aforementioned operational states can include normal operation, delayed operation, and missed operation. When the actual number of runs equals the theoretical number of runs, the task's operational state is considered normal, indicating that the task's periodic requirements can be met within this timeframe. If the actual number of runs is less than the theoretical number of runs, the task's operational state is marked as delayed operation, indicating that the task failed to run on time for some periods, potentially affecting the real-time performance of data processing and the integrity of data transmission. In more severe cases, if multiple periods consecutively fail to run, this may mean that the task's operational state has reached the missed operation state, severely impairing system performance and requiring immediate attention and correction.

[0104] In this embodiment, by monitoring and comparing the actual number of runs of periodic tasks with the theoretical number of runs, the system's CPU load and its impact on task execution can be monitored in real time. This allows for the early detection of potential delays or omissions in periodic tasks that could degrade system performance, enabling measures to be taken to optimize code or adjust task priorities, reducing the likelihood of failures. Identifying delayed tasks allows for in-depth analysis of the reasons for their excessively long execution times, optimizing task design, reducing unnecessary resource consumption, and improving overall system performance. Based on runtime status analysis, CPU resources can be allocated more rationally, ensuring that critical periodic tasks receive sufficient time slices and maintaining system real-time performance and stability. Especially for data-intensive periodic tasks, monitoring their runtime status ensures timely data processing and transmission, avoiding data loss or delays caused by high CPU load.

[0105] In summary, by monitoring the difference between the actual number of times a periodic task is run and the theoretical number of times it is run, we can not only evaluate CPU load and system performance in real time, but also effectively prevent and resolve potential latency and data loss issues in real-time systems, thereby improving system reliability and user experience.

[0106] As an optional implementation, the method may further include: in response to a delay in the operation of the second running task, determining the actual running time and theoretical running time of the second running task; and determining the cause of the delay of the second running task based on the actual running time and the theoretical running time.

[0107] In this embodiment, if the second running task experiences a delay during execution, the actual running time and theoretical running time of the second running task can be determined. Based on the actual and theoretical running times, the cause of the delay in the second running task can be determined. This cause may include, but is not limited to, abnormal kernel type, abnormal task type, and abnormal running entity.

[0108] Optionally, the runtime of basic_task / event_task / isr is compared with the OS scheduling time. Because tasks can be interrupted, there are two runtimes for a task: the theoretical runtime (T_theor) and the actual runtime (T_actual). The theoretical runtime can be used to characterize the time when the current task is interrupted and can be used to determine the expected maximum runtime. The actual runtime can be used to characterize the actual runtime of the current task and can be used to determine the maximum runtime.

[0109] For example, taking a 5ms task as an example, when entering the 5ms task, the `SetLabel_5ms` and the current start time `t_in` of the 5ms task are recorded. When leaving the task, the `SetLabel_5ms` label is cleared, and the current end time `t_out` is recorded. Simultaneously, the actual running time of this second running task, `T_actual = t_out – t_in`, is calculated. If the 5ms task is interrupted by other tasks, the execution time of the interrupting task, `T_interrupt`, is calculated in the same way. Finally, the theoretical running time, `T_theor = T_actual – T_interrupt`, can be obtained.

[0110] Optionally, the actual runtime T_actual for each task has a maximum value, which varies depending on the OS design. Each OS has a scheduling time slice, which is an interrupt ISR task. This interrupt ISR task is responsible for periodically scheduling all system function tasks. Suppose this interrupt is scheduled in 1ms cycles. Currently, the 5ms task is active, and the next 1ms is to activate the 10ms task. However, the 5ms task's runtime T_actual = 2ms. Therefore, the 10ms task is blocked. If a higher-priority task is activated in the next 1ms, the 10ms task will be continuously blocked. Therefore, the actual runtime T_actual for each task must be less than the OS's scheduling time.

[0111] Optionally, if the theoretical execution time differs significantly from the actual execution time, it indicates that the current task has been interrupted too many times, and this is not the fault of this module. In this case, it is necessary to consider which tasks interrupted the current task, causing the excessively long execution time. Therefore, if the actual execution time differs greatly from the theoretical execution time, further analysis of the CPU's operating data can be performed to determine the cause of the delay in the second running task. This cause of delay can also be referred to as the cause of the anomaly.

[0112] Optionally, during the operation of the operating system (OS), the software monitors the system's running status in real time with the precision of the OS scheduling time. If a high load risk arises, the "high load environment variable" can be updated and recorded in real time for log storage and output. The high load environment variable can reflect the current "abnormal kernel type", "abnormal task type", "abnormal running entity", and "abnormal cause".

[0113] Optionally, Table 1 shows the test results. As shown in Table 1, using the above method, the load rate, maximum running time, expected maximum running time, average running time, actual number of runs, and theoretical number of runs corresponding to the abnormal time points can be calculated respectively. According to Table 1, it can be found that the 5ms task, which should have run 20 times at 13:43:21, actually ran 18 times, 2 fewer times. The reason is that the high-priority task 10ms took too long to run, blocking the current 5ms task. That is, according to Table 1, it can be determined that the actual number of runs and the theoretical number of runs are different, and therefore, it can be determined that the running status of the second running task is abnormal.

[0114] Table 1 Test Results

[0115]

[0116] Optionally, Table 2 is a test anomaly table. As shown in Table 2, the third checkpoint in the 10ms task took too long, causing the next 5ms task to be blocked. It can be determined that the 10ms task had an anomaly in the third checkpoint.

[0117] Table 2 Test Anomaly Table

[0118]

[0119] Optionally, the above average runtime is determined based on actual runtime. The above theoretical runtime can be determined based on the central processing unit.

[0120] Optionally, in real-time or embedded systems, the second running task can be a higher-priority task. The execution of the second running task may cause delays or blockages in other lower-priority tasks. When it is detected that the actual running time of the second running task exceeds the theoretical running time within its running cycle, or fails to be scheduled within a preset cycle, this indicates a delay. For example, if a high-priority task with a cycle of 10ms actually takes 15ms in a certain running cycle, or fails to be scheduled in multiple cycles, this will trigger a delay response mechanism.

[0121] Optionally, the actual runtime mentioned above can refer to the CPU time occupied by the second task during actual execution, which may include the total time of all executions. The theoretical runtime mentioned above can refer to the runtime estimated based on the task's cycle, priority, and design. For example, for a task with a cycle of 10ms, if the runtime of each execution does not exceed 5ms under normal circumstances, then the theoretical runtime is 5ms per cycle.

[0122] Optionally, the actual runtime can be obtained through an internal timestamp mechanism, recording the start and end times of the task and calculating the difference between the two timestamps. The theoretical runtime, on the other hand, is estimated during the task design phase based on task requirements, algorithm complexity, and system environment.

[0123] Optionally, based on actual and theoretical running times, the cause of the delay in the second running task can be determined. However, analyzing the cause of the delay is a crucial step in ensuring system stability and performance. The aforementioned causes of delay may include, but are not limited to: excessively long running time, preemption by higher-priority tasks, and hardware resource bottlenecks.

[0124] Alternatively, if the actual running time is much longer than the theoretical running time, it may be due to factors such as increased algorithm complexity within the task, intensified resource contention, or hardware resource limitations.

[0125] Optionally, in a real-time system, a high-priority task can interrupt a running low-priority task. If the actual runtime of a second running task is affected by frequent interruptions, the delay may be due to preemption by higher-priority tasks.

[0126] Alternatively, in some cases, latency may be related to bottlenecks in hardware resources (such as memory, cache, peripheral access, etc.). When hardware resources cannot meet the task requirements, latency may occur.

[0127] For example, consider a function_task (the second running task) with a period of 5ms. The theoretical execution time of this second running task is 1ms, but in a certain period, the actual execution time reached 3ms. This means that the task has a 2ms delay within the current period. Further analysis suggests that if, in a subsequent period, a high-priority task with a 10ms period actually runs for 2ms, while theoretically it only needs 1ms, then it can be inferred that the delay of the 5ms task is mainly caused by the long execution time of the 10ms task, because the 10ms task preempts the execution rights of the 5ms task during its execution.

[0128] To more accurately determine the cause of the delay, the time and duration of each interruption can be recorded. This allows analysis of which tasks interrupted the 5ms task at what time, as well as the frequency and duration of the interruptions. For example, if it is found that the 10ms task runs for a long time in multiple 5ms cycles, then it can be clearly stated that the delay of the 5ms task is mainly caused by the preemption of the 10ms task.

[0129] In this embodiment, by comparing the actual and theoretical running times of the second task, and combining this with task priority and system scheduling strategies, the specific causes of latency can be accurately identified and located. This is significant for optimizing system performance, improving task scheduling efficiency, and preventing service quality degradation of critical tasks in real-time systems. By implementing this solution, system designers can take timely measures, such as optimizing code, adjusting task priorities, or improving hardware architecture, to address latency issues and ensure the system remains stable and efficient even under high load.

[0130] In this embodiment of the application, a first running task is constructed, which can be an idle task. By monitoring multiple running times of the first running task, the running time of the second running task is determined. Based on the second running time, the load rate of the central processing unit in the operating system can be determined, thereby achieving the technical effect of improving the detection performance of the operating system and solving the technical problem of low performance detection efficiency of the operating system.

[0131] The technical solutions of the embodiments of the present invention will be illustrated below with reference to preferred embodiments.

[0132] In this embodiment, an idle task, i.e., a first running task, can be constructed.

[0133] Optionally, CPU idle load rate is the percentage of idle tasks within a certain period. An idle task (idle_task) can be designed. For an MCU OS system, an idle task refers to a task running on the OS when all other functional tasks are not running. The construction of this idle_task should meet the following requirements: lowest priority in the entire OS system, lower than ISR and function_task; type that allows preemption by higher-priority function_task / ISR; and cannot be terminated by terminate after startup.

[0134] In this embodiment, the runtime (i.e., runtime segment) of function_task can be calculated based on idle_task.

[0135] Optionally, after the Idle_task design is complete, the CPU load rate needs to be calculated. The runtime t_out of the idle_task and the runtime t_in of the next idle_task can be obtained. Then the runtime of the current function _task / isr can be calculated as t1_run = t_in - t_out.

[0136] Optionally, if t_in is used to characterize the start time of the second running task and t_out is used to characterize the end time of the second running task, then the runtime segment corresponding to the second running task can be: t1_run = t_out – t_in.

[0137] Optionally, the sources of t_out and t_in should not occupy OS resources, otherwise it will greatly affect CPU performance. Therefore, the hardware resources of the MCU can be utilized, and a hardware clock can be allocated to t_out and t_in through the hardware clock tree of the MCU.

[0138] In this embodiment, the period of load rate and the load rate calculation method can be designed.

[0139] Optionally, the CPU computation cycle is not arbitrarily determined; it needs to cover the execution time of all tasks. Therefore, it can be the current longest running time of the task, or an integer multiple thereof, to ensure that all tasks have run, or at least that all tasks have completed one cycle. For example, the computation cycle (t_cycle) can be set to the least common multiple of all cycled tasks, where n calculations of the function_task task are performed within this cycle, with execution times t1_run…tn_run. Then, the total running time of the current function_task is T_functiontask = t1_run + t2_run + … + tn_run.

[0140] Optionally, load rate calculation: cpu_load = T_functiontask / t_cycle 100%. Among them, the task currently calculating CPU load cannot be an idle task, and it is executed in the largest cycle task.

[0141] This embodiment provides a scheme for detecting function_task / isr blocking, which can reasonably utilize the characteristics of periodic tasks and refer to the OS scheduling time to reflect whether the current system is blocked. If a task is found to be blocked, data is needed to support the analysis of the reason for the blocking: whether it is due to its own long running time or being preempted by other tasks. Analysis can be approached from two directions: comparing the number of times basic_tasks run, or comparing the running time of basic_task / event_task / isr with the OS scheduling time.

[0142] Optionally, by comparing the execution counts of basic_tasks, the actual execution count of each basic_task can be calculated, and the correspondence between the "actual execution counts" can be used to reflect the task's blocking status. For example, if the current system has 5ms tasks and 10ms tasks, and of course many other tasks, then within the t_cycle time, the number of times the 5ms task runs (N_5ms) will be twice the number of times the 10ms task runs (N_10ms). If N_5ms / 2 > N_10ms, it means the 10ms task is delayed; conversely, the 5ms task is delayed.

[0143] Optionally, the actual number of runs is the number of times the OS triggers scheduling and runs, excluding scenarios where the OS is interrupted and then runs again, or scenarios where the OS is activated but not scheduled to run.

[0144] Optionally, the cause of the delay can be determined by comparing the runtime of basic_task / event_task / isr with the OS scheduling time. Since tasks can be interrupted, there are two runtimes for a task: the theoretical runtime T_theor and the actual runtime T_actual.

[0145] For example, taking a 5ms task as an example, when entering the 5ms task, the `SetLabel_5ms` and the current time `t_in` are recorded. When leaving the task, the `SetLabel_5ms` label is cleared, and the current time `t_out` is recorded. Simultaneously, the actual running time `T_actual` = `t_out` – `t_in` is calculated. If the 5ms task is interrupted by other tasks, the execution time of the interrupting task `T_interrupt` is calculated in the same way. Finally, the theoretical running time `T_theor` = `T_actual` – `T_interrupt` can be obtained.

[0146] Optionally, the role of T_actual is to ensure that the actual runtime of each task has a maximum value, which varies depending on the OS design. Each OS has a scheduling time slice, which is an interrupt ISR task. This interrupt ISR task is responsible for periodically scheduling all system function tasks. Suppose this interrupt is scheduled in 1ms cycles. Currently, a 5ms task is active, and the next 1ms is to activate a 10ms task. However, the 5ms task's runtime T_actual = 2ms. Therefore, the 10ms task is blocked. If a higher-priority task is activated in the next 1ms, the 10ms task will be continuously blocked. Therefore, the actual runtime T_actual of each task must be less than the OS's scheduling time.

[0147] Optionally, the role of T_theor is to determine which tasks interrupted the current task too many times if the theoretical running time differs significantly from the actual running time. This is not the fault of this module, and it is necessary to consider which tasks interrupted the current task, resulting in the excessive running time.

[0148] This embodiment involves an MCU CPU performance detection scheme that monitors MCU execution for data loss and queries the causes of real-time system task blocking due to multi-task contention. It can quickly pinpoint the cause of data frame loss under high load conditions, thereby improving the technical efficiency of operating system performance detection and solving the technical problem of low operating system performance detection efficiency.

[0149] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, use and processing of the relevant data must comply with the relevant laws, regulations and standards of the relevant countries and regions, and corresponding operation entry points are provided for users to choose to authorize or refuse.

[0150] According to an embodiment of this application, an embodiment of a processor load rate determination system is also provided. It should be noted that this system can be used to run the above-described processor load rate determination method.

[0151] According to an embodiment of this application, an embodiment of a processor load rate determination device is also provided. It should be noted that the device can be used to run the above-described processor load rate determination method.

[0152] Figure 6 This is a schematic diagram of a processor load rate determination device according to an embodiment of this application. Figure 6As shown, the processor load rate determination device may include: an acquisition unit 602, a first determination unit 604, and a second determination unit 606.

[0153] The acquisition unit 602 is used to acquire multiple running moments of the controller's central processing unit running the first running task during the operation of the operating system in the controller.

[0154] The first determining unit 604 is used to determine, based on multiple runtime times, at least one runtime segment in which the central processing unit runs at least one second running task, wherein, when the second running task is running, the priority of the second running task is greater than the priority of the first running task.

[0155] The second determining unit 606 is used to determine the load rate of the central processing unit based on at least one runtime period.

[0156] Furthermore, the second determining unit 606 may include: a first determining module, used to determine a calculation cycle based on at least one running cycle of at least one second running task; a second determining module, used to determine a total running time based on at least one running time; and a conversion module, used to convert the total running time using the calculation cycle to obtain the load rate.

[0157] Furthermore, the first determining module may include: a first determining submodule, used to determine the least common multiple of at least one running cycle as the calculation cycle.

[0158] Furthermore, the second determining module may include: a second determining submodule, used to determine the sum of at least one runtime segment as the total runtime segment.

[0159] Furthermore, the conversion module may include a third determining submodule, used to determine the load rate as the quotient between the total runtime and the computation cycle.

[0160] Furthermore, the acquisition unit 602 may include: a first processing module, configured to stop running the first running task in response to starting to run the second running task, and acquire the running end time of the first running task; and an acquisition module, configured to acquire the running start time of the first running task in response to ending to run the second running task and starting to run the first running task, wherein the multiple running times include the running start time and the running end time.

[0161] Optionally, the first determining unit 604 may include: a third determining module, used to determine the difference between the end time of the run and the start time of the run as the second run segment of the second run task.

[0162] Furthermore, the device can also be used to determine the actual number of runs and the theoretical number of runs of at least one periodic task in at least one second running task; compare the actual number of runs and the theoretical number of runs to obtain a comparison result, wherein the comparison result is used to characterize the magnitude relationship between the actual number of runs and the theoretical number of runs; and based on the comparison result, determine the running status of the periodic task, wherein the running status is used to characterize the delay of the periodic task.

[0163] Furthermore, the device can also be used to determine the actual running time and theoretical running time of the second running task in response to a delay during its operation; and to determine the cause of the delay of the second running task based on the actual and theoretical running times.

[0164] In the processor load rate determination device of this embodiment, the acquisition unit acquires multiple running times of the central processing unit (CPU) running a first running task during the operation of the operating system in the controller; the first determination unit determines at least one running segment of the CPU running at least one second running task based on the multiple running times, wherein, when the second running task is running, the priority of the second running task is greater than the priority of the first running task; the second determination unit determines the CPU load rate based on the at least one running segment, thereby achieving the technical effect of improving the performance detection efficiency of the operating system and solving the technical problem of low performance detection efficiency of the operating system.

[0165] Embodiments of this application also provide a vehicle, including: a memory storing an executable program; and a processor for running the program, wherein the program executes the methods described in various embodiments of this application.

[0166] Embodiments of this application also provide a computer-readable storage medium including a stored executable program, wherein, when the executable program is running, it controls the device where the computer-readable storage medium is located to perform the methods of various embodiments of this application.

[0167] Embodiments of this application also provide a computer program product, including a computer program that implements the methods of various embodiments of this application when run by a processor.

[0168] Embodiments of this application also provide a computer program product, including a non-volatile computer-readable storage medium for storing a computer program, which is executed by a processor to implement the methods in various embodiments of this application.

[0169] Embodiments of this application also provide a computer program that, when run by a processor, implements the methods described in the various embodiments of this application.

[0170] In the above embodiments of this application, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0171] 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 operational. Furthermore, the displayed or discussed mutual coupling, direct coupling, or communication connection may be through some interfaces; the indirect coupling or communication connection of units or modules may be electrical or other forms.

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

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

[0174] If 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 run all or part of the steps of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard drive, magnetic disk, or optical disk.

[0175] The above are merely preferred embodiments of this application. It should be noted that those skilled in the art can make various improvements and modifications without departing from the principles of this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. A method for determining the load rate of a processor, characterized in that, include: During the operation of the operating system in the controller, multiple execution moments of the controller's central processing unit running the first execution task are obtained; Based on multiple said running times, at least one running segment is determined in which the central processing unit runs at least one second running task, wherein, when the second running task is running, the priority of the second running task is greater than the priority of the first running task; The load rate of the central processing unit is determined based on at least one of the runtime segments.

2. The method according to claim 1, characterized in that, Determining the load rate of the central processing unit based on at least one of the runtime segments includes: The calculation cycle is determined based on at least one running cycle of at least one of the second running tasks; Determine the total number of runtime segments based on at least one of the aforementioned runtime segments; The total runtime is converted using the calculation cycle to obtain the load rate.

3. The method according to claim 2, characterized in that, Determining the computation cycle based on at least one execution cycle of at least one of the second running tasks includes: The least common multiple of at least one of the aforementioned operating cycles is determined as the calculation cycle.

4. The method according to claim 2, characterized in that, Determining the total number of runtime segments based on at least one of the runtime segments includes: The sum of at least one of the aforementioned runtime segments is determined as the total runtime segments.

5. The method according to claim 2, characterized in that, The step of converting the total runtime using the calculation cycle to obtain the load rate includes: The load rate is determined by the quotient between the total runtime and the calculation cycle.

6. The method according to claim 1, characterized in that, During the operation of the operating system in the controller, multiple execution times of the controller's central processing unit running the first task are obtained, including: In response to starting the second running task, stop running the first running task, and obtain the end time of the first running task; In response to ending the second running task and starting the first running task, the running start time of the first running task is obtained, wherein the plurality of running times include the running start time and the running end time; Determining at least one runtime segment of the central processing unit running at least one second running task based on multiple running times includes: determining the difference between the running end time and the running start time as the second runtime segment of the second running task.

7. The method according to any one of claims 1 to 6, characterized in that, The method further includes: Determine the actual number of runs and the theoretical number of runs for at least one cycle task in at least one of the second running tasks; The actual number of runs is compared with the theoretical number of runs to obtain a comparison result, wherein the comparison result is used to characterize the relationship between the actual number of runs and the theoretical number of runs; Based on the comparison results, the running status of the periodic task is determined, wherein the running status is used to characterize the delay of the periodic task.

8. The method according to any one of claims 1 to 6, characterized in that, The method further includes: In response to the delay in the second running task during its operation, the actual running time and theoretical running time of the second running task are determined; Based on the actual running time and the theoretical running time, the cause of the delay in the second running task is determined.

9. A vehicle, characterized in that, include: Memory, which stores executable programs; A processor for running the program, wherein the program, when running, performs the method according to any one of claims 1 to 8.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium includes a stored executable program, wherein, when the executable program is executed, it controls the device on which the storage medium is located to perform the method of any one of claims 1 to 8.

Images