Vehicle system fault detection method, device, equipment and readable storage medium

Abstract

The application provides a vehicle-mounted system fault detection method, device and equipment and a readable storage medium, which can load a kernel module of a vehicle-mounted system; a corresponding memory ring buffer area is created for each CPU in the kernel module, and a first processing function is inserted at a function point of process switching and awakening; when the process is switched and awakened, the first processing function can be called, and the scheduling record of calling the first processing function and the calling process is written into the memory ring buffer area corresponding to the CPU corresponding to the process, so that the calling record of the process can be recorded. When the vehicle-mounted system fails or alarms, the kernel module can be notified to write the scheduling record in the memory ring buffer area of each CPU into a disk, so as to detect the fault of the vehicle-mounted system. Maintenance personnel can help to timely eliminate the fault, so as to ensure that the vehicle-mounted system can normally operate.

Description

Technical Field

[0001] This application relates to the field of process failure analysis technology, and in particular to a method, apparatus, device and readable storage medium for detecting faults in vehicle systems. Background Technology

[0002] With the development of science and technology, the performance of vehicle-mounted systems has also improved significantly. However, in practical applications, due to limited resources, vehicle-mounted systems may experience malfunctions, such as scheduling delays in some processes. Process scheduling delay refers to the time required for a process to transition from a ready-to-run state to a running state. When processes in a vehicle-mounted system encounter significant scheduling delays, it can have a substantial impact on the system, such as the inability to receive sensor data in a timely manner or to process received data promptly.

[0003] There are many reasons for process scheduling delays in vehicle systems: for example, the CPU may be unable to handle the workload, a process may disable hardware interrupts during execution, preventing the CPU from scheduling processes in a timely manner, or the CPU may be occupied by a high-priority process for a short period of time. Furthermore, process scheduling delays are characterized by their very short duration and low probability of occurrence; typically, the delay lasts from about 10ms to 200ms and disappears almost instantly, and it is difficult to predict when the delay will occur. To ensure the stable operation of the vehicle system, it is necessary to analyze the specific causes of the scheduling delays so that faults can be eliminated promptly. Summary of the Invention

[0004] This application aims to at least solve one of the aforementioned technical defects. In view of this, this application provides a method, apparatus, device and readable storage medium for detecting vehicle system faults, in order to solve the technical defect of difficulty in detecting vehicle system faults in the prior art.

[0005] A method for detecting faults in an in-vehicle system, comprising:

[0006] Load the kernel module of the vehicle system;

[0007] In the kernel module, a corresponding memory circular buffer is created for each CPU, wherein the memory circular buffer is used to cyclically store the scheduling records of the corresponding CPU;

[0008] Insert a custom first processing function at the function point where the first target process switches and is woken up;

[0009] When the first target process is switched and woken up, the first processing function is called, and the scheduling record of the first processing function call and the call to the first target process is written into the memory ring buffer corresponding to the CPU of the first target process.

[0010] When a fault or alarm occurs in the vehicle system, the kernel module is notified to write the scheduling records in the memory ring buffer of each CPU to the disk for detecting the fault in the vehicle system.

[0011] Preferably, the method further includes:

[0012] Based on the scheduling records of the first target process, calculate the duration of each scheduling delay of the first target process.

[0013] Preferably, the method further includes:

[0014] Determine whether the scheduling delay of the first target process exceeds a preset first threshold;

[0015] If the scheduling delay of the first target process exceeds a preset first threshold, the cause of the scheduling delay in the first target process is determined based on the scheduling delay of the first target process.

[0016] Preferably, calculating the duration of each scheduling delay of the first target process based on the scheduling record of the first target process includes:

[0017] Based on the scheduling record of the first target process, determine the time when the first target process was loaded into a CPU that was allowed to execute, the time when it was last loaded out of a CPU that was allowed to execute and was in a ready state, or the time when the first target process was last woken up.

[0018] Based on the time when the first target process is loaded into the CPU that is allowed to execute and the time when it was last loaded out of the CPU that is allowed to execute and is in the ready state, the duration of each scheduling delay of the first target process is calculated, wherein the duration of each scheduling delay of the first target process is equal to the time interval between the time when the first target process is loaded into the CPU that is allowed to execute and the time when the first target process was last loaded out of the CPU that is allowed to execute and is in the ready state.

[0019] or,

[0020] Based on the time when the first target process is loaded into the CPU that is allowed to execute and the time when the first target process is last woken up, the duration of each scheduling delay of the first target process is calculated, wherein the duration of each scheduling delay of the first target process is equal to the time interval between the time when the first target process is loaded into the CPU that is allowed to execute and the time when the first target process is last woken up.

[0021] Preferably, the method further includes:

[0022] The runtime of each process is monitored in real time to determine the runtime of each process. The runtime of each process is equal to the time interval between when each process is loaded into the CPU for execution and when each process is loaded out of the CPU.

[0023] Determine if there are any processes whose runtime exceeds a preset second threshold;

[0024] If there is a process whose runtime exceeds the preset second threshold, then the process whose runtime exceeds the preset second threshold is determined as the second target process;

[0025] Record the call stack of the second target process in kernel mode in the system log so as to analyze the reason why the second target process runs for too long using the call stack of the second target process.

[0026] Preferably, determining whether the runtime of each process exceeds a preset second threshold includes:

[0027] Modify the data structure of each process in the system's kernel module, and add a target field to the data structure of each process. The target field of the process's data structure is used to store the time point when the process state changes.

[0028] Load the system's kernel module, start a kernel timer, and set the execution conditions of the kernel timer on the hardware terminal;

[0029] Insert the first processing function at each process switching function point. In the inserted first processing function, when the process is switched off the CPU or switched into the CPU, record the time point at that time in the target field of the process's data structure.

[0030] In the kernel timer's processing function, the runtime of the current process is determined based on the record of the target field in the process's data structure to see if it exceeds a preset second threshold.

[0031] Preferably, determining the cause of the scheduling delay in the first target process based on the scheduling delay duration of the first target process includes:

[0032] Determine the target time period in which the scheduling delay of the first target process occurs;

[0033] Determine the set of target CPUs in the system's kernel module that are allowed to execute the first target process within the target time period;

[0034] The statistics show the duration of each process using each CPU within the target CPU set during the target time period.

[0035] Based on a preset first condition, the cause of the scheduling delay in the first target process is determined, wherein the preset first condition includes:

[0036] The priority of each process in the target CPU set;

[0037] or,

[0038] The priority of each process in the target CPU set and the duration of CPU usage;

[0039] or,

[0040] The priority of each process in the target CPU set, the duration of each CPU being used, the utilization rate of each CPU in the target CPU set, and the runtime of each process in the target CPU set.

[0041] Preferably, determining the cause of the scheduling delay in the first target process based on the priority of each process in the target CPU set includes:

[0042] Based on the priority of each process in the target CPU set, determine whether there is a process in the target CPU set with a higher priority than the first target process;

[0043] If there is a process in the target CPU set with a higher priority than the first target process, then the cause of the scheduling delay in the first target process is determined to be that the priority settings of each process in the target CPU set are unreasonable.

[0044] Preferably, determining the cause of the scheduling delay in the first target process based on the priority of each process in the target CPU set and the duration of CPU usage includes:

[0045] Based on the priority of each process in the target CPU set, determine whether there is a process in the target CPU set with a higher priority than the first target process;

[0046] If there is no process in the target CPU set with a priority higher than that of the first target process, then it is determined whether there is a process in the target CPU set whose CPU usage time exceeds a preset third threshold.

[0047] If there is a process in the target CPU set whose CPU usage time exceeds the preset third threshold, then check the running records of the processes in the target CPU set whose running time exceeds the preset second threshold, determine the processes in the target CPU set whose running time exceeds the preset second threshold as the second target processes, and determine the cause of the scheduling delay in the first target process based on the running records of the second target processes.

[0048] Preferably, determining the cause of the scheduling delay in the first target process based on the priority of each process in the target CPU set, the duration of each CPU usage, the utilization rate of each CPU in the target CPU set, and the runtime of each process in the target CPU set includes:

[0049] Based on the priority of each process in the target CPU set, determine whether there is a process in the target CPU set with a higher priority than the first target process;

[0050] If there is no process in the target CPU set with a priority higher than that of the first target process, then it is determined whether there is a process in the target CPU set whose CPU usage time exceeds a preset third threshold.

[0051] If there is no process in the target CPU set where the duration of a single CPU used exceeds the preset third threshold, then it is determined whether there are cases in the target CPU set where the utilization rate of some CPUs exceeds the preset fourth threshold and the utilization rate of some CPUs is lower than the preset fourth threshold.

[0052] If some CPUs in the target CPU set have a utilization rate exceeding the preset fourth threshold, while some CPUs have a utilization rate below the preset fourth threshold, then the cause of the scheduling delay in the first target process is determined to be that the grouping of the CPUs in the target CPU set is unreasonable, resulting in uneven use of the CPUs.

[0053] Preferably, determining the cause of the scheduling delay in the first target process based on the priority of each process in the target CPU set, the duration of each CPU usage, the utilization rate of each CPU in the target CPU set, and the runtime of each process in the target CPU set includes:

[0054] Based on the priority of each process in the target CPU set, determine whether there is a process in the target CPU set with a higher priority than the first target process;

[0055] If there is no process in the target CPU set with a priority higher than that of the first target process, then it is determined whether there is a process in the target CPU set whose CPU usage time exceeds a preset third threshold.

[0056] If there is no process in the target CPU set where the duration of a single CPU used exceeds the preset third threshold, then it is determined whether there are cases in the target CPU set where the utilization rate of some CPUs exceeds the preset fourth threshold and the utilization rate of some CPUs is lower than the preset fourth threshold.

[0057] If there is no situation in the target CPU set where the utilization rate of some CPUs exceeds the preset fourth threshold and the utilization rate of some CPUs is lower than the preset fourth threshold, then it is determined whether the utilization rate of any CPU in the target CPU set exceeds the preset fifth threshold.

[0058] If the utilization rate of any CPU in the target CPU set exceeds the preset fifth threshold, then the cause of the scheduling delay in the first target process is determined to be that all CPUs in the target CPU set are fully loaded, and it is necessary to consider expanding the number of CPUs.

[0059] Preferably, determining the cause of the scheduling delay in the first target process based on the priority of each process in the target CPU set, the duration of each CPU usage, the utilization rate of each CPU in the target CPU set, and the runtime of each process in the target CPU set includes:

[0060] Based on the priority of each process in the target CPU set, determine whether there is a process in the target CPU set with a higher priority than the first target process;

[0061] If there is no process in the target CPU set with a priority higher than that of the first target process, then it is determined whether there is a process in the target CPU set whose CPU usage time exceeds a preset third threshold.

[0062] If there is no process in the target CPU set where the duration of a single CPU used exceeds the preset third threshold, then it is determined whether there are cases in the target CPU set where the utilization rate of some CPUs exceeds the preset fourth threshold and the utilization rate of some CPUs is lower than the preset fourth threshold.

[0063] If there is no situation in the target CPU set where the utilization rate of some CPUs exceeds the preset fourth threshold and the utilization rate of some CPUs is lower than the preset fourth threshold, then it is determined whether the utilization rate of any CPU in the target CPU set exceeds the preset fifth threshold.

[0064] If there is a CPU in the target CPU set whose utilization rate does not exceed the preset fifth threshold, then the cause of the scheduling delay in the first target process is determined to be untimely task migration or a defect in the scheduler.

[0065] A vehicle-mounted system fault detection device, comprising:

[0066] The module loading unit is used to load the kernel module of the vehicle system;

[0067] A buffer creation unit is used to create a corresponding memory circular buffer for each CPU in the kernel module, wherein the memory circular buffer is used to cyclically store the scheduling records of the corresponding CPU;

[0068] The first function insertion unit is used to insert a custom first processing function at the function point where the first target process is switched and woken up.

[0069] The first editing unit is used to call the first processing function when the first target process is switched and woken up, and write the scheduling record of calling the first processing function and calling the first target process into the memory ring buffer corresponding to the CPU of the first target process;

[0070] The second editing unit is used to notify the kernel module to write the records in the memory ring buffer of each CPU to the disk when the vehicle system malfunctions or alarms, so as to detect the malfunction of the vehicle system.

[0071] An in-vehicle system fault detection device includes: one or more processors, and a memory;

[0072] The memory stores computer-readable instructions, which, when executed by the one or more processors, implement the steps of the vehicle system fault detection method as described above.

[0073] A readable storage medium storing computer-readable instructions, which, when executed by one or more processors, cause the one or more processors to perform the steps of the vehicle system fault detection method described in any of the foregoing descriptions.

[0074] As can be seen from the above technical solutions, the method provided in this application embodiment can load the kernel module of the vehicle system; and create a corresponding memory circular buffer for each CPU in the kernel module. The memory circular buffer is used to cyclically store the scheduling records of the corresponding CPU, so that when a fault occurs in the vehicle system, the CPU scheduling records can be obtained from the memory circular buffer to analyze the cause of the fault. Simultaneously, a custom first processing function can be inserted at the function point where the first target process switches and wakes up. When the first target process switches and wakes up, the first processing function can be called, and the scheduling record of the first processing function call and the call to the first target process can be written into the memory circular buffer corresponding to the CPU of the first target process, so that the call record of the first target process can be recorded. When a fault or alarm occurs in the vehicle system, the kernel module can be notified to write the scheduling records in the memory circular buffers of each CPU to the disk for detecting faults in the vehicle system. Therefore, the method provided in this application embodiment can determine the specific cause of process scheduling delay based on the process scheduling records, so as to help maintenance personnel troubleshoot in a timely manner and ensure that the vehicle system can operate normally. Attached Figure Description

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

[0076] Figure 1 A flowchart illustrating a method for detecting faults in an in-vehicle system, provided as an embodiment of this application;

[0077] Figure 2 A flowchart illustrating another method for detecting faults in a vehicle system provided in this application embodiment;

[0078] Figure 3 A flowchart illustrating another method for detecting faults in a vehicle system provided in this application embodiment;

[0079] Figure 4 A flowchart illustrating another method for detecting faults in a vehicle system provided in this application embodiment;

[0080] Figure 5 A flowchart illustrating another method for detecting faults in a vehicle system provided in this application embodiment;

[0081] Figure 6A flowchart illustrating another method for detecting faults in a vehicle system provided in this application embodiment;

[0082] Figure 7 A flowchart illustrating another method for detecting faults in a vehicle system provided in this application embodiment;

[0083] Figure 8 A flowchart illustrating another method for detecting faults in a vehicle system provided in this application embodiment;

[0084] Figure 9 A flowchart illustrating another method for detecting faults in a vehicle system provided in this application embodiment;

[0085] Figure 10 A flowchart illustrating another method for detecting faults in a vehicle system provided in this application embodiment;

[0086] Figure 11 This is a schematic diagram illustrating the structure of an in-vehicle system fault detection device, as exemplified by an embodiment of this application.

[0087] Figure 12 This is a hardware structure block diagram of a vehicle system fault detection device disclosed in an embodiment of this application. Detailed Implementation

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

[0089] In computer science, the kernel is the most fundamental part of an operating system. The kernel is a piece of software that provides secure access to computer hardware for numerous applications. This access is limited, and the kernel determines when a program can operate on a particular part of the hardware and for how long. Directly manipulating the hardware is very complex, so the kernel typically provides a hardware abstraction method to accomplish these operations.

[0090] Hardware abstraction hides complexity, providing a simple and unified interface for application software and hardware, making program design simpler. Simply put, the kernel acts as a bridge between the upper and lower layers. The kernel receives requests from software and allocates corresponding resources, while the kernel allocates hardware resources appropriately to provide services to the upper layers.

[0091] A process is a dynamic execution of a program. It is the basic and smallest unit of resource allocation by the operating system. When the kernel receives a task, it creates a process to execute that task, and the process's resources are allocated by the kernel. The kernel maintains a process table to record processes. If there is only a single process, that process exclusively uses the CPU. If multiple tasks arrive, the kernel creates multiple processes to execute different tasks, and CPU usage is allocated to each process through a time-slice rotation. Processes queue up to use the CPU. When a process finishes using the CPU for a certain period, it stops and hands over the CPU to the next process, with processes taking turns using the CPU. Because the CPU runs very fast, users do not perceive any CPU pauses.

[0092] Therefore, during the execution of a process, it can be divided into three states: ready state, running state, and blocked state.

[0093] A process is in the ready state when it has all the conditions to execute and is just waiting to obtain the right to use the CPU. Once the CPU right is allocated to a process in the ready state, the process can enter the running state.

[0094] A process being in the running state means that the process is using the CPU.

[0095] A process being in a blocked state means that while the process is in the running state, it lacks data and needs to retrieve the data from memory. However, the operating speed of memory and CPU differs greatly, so the CPU will put the process in a blocked state and let the next process enter the running state first. Once the process in the blocked state retrieves the data from memory, it will be queued, enter the ready state, and then enter the running state. It is not possible to go directly from the blocked state to the running state.

[0096] Threads are created by processes, processes are created by the kernel, and process resources are allocated by the kernel; thread resources are allocated by the process. A process can create multiple threads. Threads do not communicate with each other, but processes can communicate with each other through pipes, message queues, signals, shared memory, semaphores, etc. Threads do not communicate with each other, but conflicts can occur when threads access the same shared resource. Threads have their own way of handling this: setting a mutex lock ensures that they exclusively possess the resource during its use, releasing it afterward. Other threads cannot use the resource while this thread is using it, thus avoiding conflicts.

[0097] In summary, the kernel creates processes, processes are managed by the kernel, and threads are created by processes. The kernel does not manage threads.

[0098] Given that most current in-vehicle system fault detection solutions struggle to quickly pinpoint the cause of process scheduling delays, this applicant has developed an in-vehicle system fault detection and localization solution. This solution can analyze and locate the cause of process scheduling delays, helping basic developers accurately pinpoint the storage location of the fault and promptly conduct fault tracing and repair.

[0099] The methods provided in this application can be used in a variety of general-purpose or special-purpose computing device environments or configurations. For example: personal computers, server computers, handheld or portable devices, tablet devices, multiprocessor devices, distributed computing environments including any of the above devices, etc.

[0100] This application provides a method for detecting faults in a vehicle system. This method can be applied to the vehicle systems of various vehicles or the airborne systems of flight equipment, and can also be applied to various computer terminals or smart terminals. The executing entity can be the processor or server of the computer terminal or smart terminal.

[0101] The following is combined Figure 1 This application describes the flowchart of a vehicle system fault detection method according to embodiments, which may include the following steps:

[0102] Step S101: Load the operating system kernel module.

[0103] Specifically, as described above, the kernel module of the operating system can receive requests from software, allocate corresponding resources to the software, and rationally allocate hardware resources according to different needs to provide services to the upper layer.

[0104] The kernel module can create processes as needed, and these processes are managed by the kernel module itself. Therefore, to determine the cause of scheduling delays in the vehicle system's processes, the kernel module of the vehicle system can be loaded first to analyze the status of each process within it.

[0105] Step S102: In the kernel module, a corresponding memory circular buffer is created for each CPU, wherein the memory circular buffer is used to cyclically store the scheduling records of the corresponding CPU.

[0106] Specifically, in computer science, a circular buffer, also known as a circular queue or circular buffer, is a data structure used to represent a fixed-size, contiguous buffer, suitable for buffering data streams.

[0107] In practical applications, to store CPU call records, a corresponding circular memory buffer can be created for each CPU in the kernel module. This circular buffer can be used to cyclically store the CPU scheduling records. This allows for analysis of the cause of a malfunction in the vehicle system by consulting the CPU scheduling records.

[0108] Step S103: Insert a custom first processing function at the function point where the first target process switches and is woken up.

[0109] Specifically, as can be seen from the above introduction, a process can be divided into three states during the execution process: ready state, running state, and blocked state.

[0110] Process switching is a fundamental function that modern multitasking, multi-user operating systems should possess. In order to control the execution of processes, the operating system must be able to suspend a process currently running on the CPU and resume the execution of a previously suspended process. This behavior is called process switching, task switching, or context switching.

[0111] In other words, process switching refers to reclaiming the processor from a running process and then allowing the waiting process to take over the processor.

[0112] Reclaiming the processor from a process essentially involves storing the process's intermediate data in the processor's registers elsewhere, thus freeing up those registers for other processes. Therefore, the intermediate data of the terminated process must be stored elsewhere. For example, it can be stored in the process's private stack.

[0113] When processes communicate in a blocking manner, they may suspend and enter a sleep state until a result is obtained. To ensure a process enters a safe sleep state, it should be unaware of its environment after entering sleep. Process sleep can include simple sleep and advanced sleep.

[0114] When a process enters a sleep state, if available resources become available and the process needs to continue execution, a process wake-up function is required to wake up the sleeping process.

[0115] Therefore, in order to better record the scheduling records of the first target process, a custom first processing function can be inserted at the function points where the first target process is switched and woken up.

[0116] The first processing function is used to record the scheduling records of switching or waking up the first target process.

[0117] Each scheduling record for a process can include the following information:

[0118] (1) When a process switch occurs, each scheduling record for the process may include:

[0119] Information such as the time of process switching, the ID of the process being switched off the CPU, the state of the process being switched off the CPU, the ID and name of the process being switched into the CPU, the priority of the process being switched into the CPU, and the CPU ID.

[0120] (2) When a process is woken up, each scheduling record for the process may include:

[0121] Information such as the time when a process is awakened, the ID and name of the awakened process, the CPU ID, the ID of the process that was moved from the CPU, the ID of the process that was moved into the CPU, the state of the process that was moved from the CPU, and the priority of the process that was moved into the CPU.

[0122] Step S104: When the first target process is switched and woken up, the first processing function is called, and the scheduling record of calling the first processing function and calling the first target process is written into the memory ring buffer corresponding to the CPU of the first target process.

[0123] Specifically, as described above, the method provided in this application embodiment can insert a custom processing function at the function point where a process switches or wakes up to handle the process switching or wake-up.

[0124] When a process is awakened, it means that the process has entered the ready state. The process state reflects the changes in the process execution process. Awakening a process means activating the process, which means that the awakened process changes from the dormant state to the ready state. It also means that the process has the conditions to run and is waiting for the system to allocate a processor for it to run. However, after entering the ready state, it does not immediately move to the head of the ready queue, but joins the queue at the tail.

[0125] Therefore, in practical applications, in order to better record the scheduling records of the switching or waking of the first target process, when the first target process is switched or woken up, the first processing function can be called, and the scheduling records of calling the first processing function and calling the first target process can be written into the memory circular buffer corresponding to the CPU of the first target process.

[0126] Step S105: When a fault or alarm occurs in the vehicle system, the kernel module is notified to write the scheduling records in the memory ring buffer of each CPU to the disk for detecting the fault in the vehicle system.

[0127] Specifically, in practical applications, when an in-vehicle system malfunctions, it can issue an alarm. When an in-vehicle system malfunctions or issues an alarm, it indicates that maintenance is required. Since maintenance is necessary, it's essential to understand the cause of the malfunction or alarm. This necessitates analyzing the in-vehicle system's process scheduling records.

[0128] Therefore, when a fault or alarm occurs in the vehicle system, the kernel module can be notified to write the scheduling records in the memory ring buffer of each CPU to the disk, so that the fault in the vehicle system can be detected or analyzed.

[0129] As can be seen from the technical solutions described above, the method provided in this application embodiment can create a corresponding memory ring buffer for each CPU of the kernel module of the vehicle system to store the scheduling records of the process. When the vehicle system fails or alarms, the scheduling records in the memory ring buffers of each CPU can be written to the disk so that the faults of the vehicle system can be detected and eliminated in a timely manner through the scheduling records stored on the disk.

[0130] As described above, the method provided in this application embodiment can create a corresponding memory circular buffer for each CPU of the kernel module of the vehicle system to store process scheduling records. When a fault or alarm occurs in the vehicle system, the scheduling records in the memory circular buffers of each CPU can be written to disk. In practical applications, using the scheduling records stored on disk, the method provided in this application embodiment can further determine the duration of each process scheduling delay. The process is described below and may include the following:

[0131] Based on the scheduling records of the first target process, calculate the duration of each scheduling delay of the first target process.

[0132] Specifically, as described above, the method provided in this application embodiment can record each scheduling record of a process, and each scheduling record of a process can provide feedback on the scheduling status of the process.

[0133] For example, process scheduling records can provide feedback on when a process is loaded into or removed from the CPU. Therefore, based on the scheduling records of the first target process, the duration of each scheduling delay for the first target process can be calculated.

[0134] Determining the duration of the scheduling delay of the first target process can be used to further analyze the specific reasons for the process scheduling delay in the vehicle system.

[0135] The calculation of the duration of each scheduling delay of the first target process based on the scheduling record of the first target process can include the following two implementation methods:

[0136] The first type,

[0137] Step S201: Based on the scheduling record of the first target process, determine the time when the first target process was loaded into the CPU that was allowed to execute and the time when it was last loaded out of the CPU that was allowed to execute and was in the ready state.

[0138] Specifically, as can be seen from the above description, the method provided in the embodiments of this application can record the scheduling record of the process, and the scheduling record of the process can provide feedback on the time when the process is called into the CPU or called out of the CPU.

[0139] Therefore, based on the scheduling records of the first target process, the time when the first target process was loaded into a CPU allowed for execution and the time when it was last loaded out of a CPU and entered a ready state can be determined. This can then be used to calculate the duration of each scheduling delay for the first target process.

[0140] Step S202: Based on the time when the first target process was loaded into the CPU that was allowed to execute and the time when it was last loaded out of the CPU that was allowed to execute and was in the ready state, calculate the duration of each scheduling delay of the first target process.

[0141] Specifically, as can be seen from the above description, the above steps can obtain the time when the first target process was loaded into the CPU that was allowed to execute and the time when it was last loaded out of the CPU that was allowed to execute and was in the ready state from the scheduling record of the first target process. Based on this, the duration of each scheduling delay of the first target process can be calculated.

[0142] Wherein, the duration of each scheduling delay of the first target process is equal to the time interval between the moment when the first target process is loaded into the CPU that is allowed to execute and the moment when the first target process is last loaded out of the CPU that is allowed to execute and is in a ready state.

[0143] The second type,

[0144] Step S301: Based on the scheduling record of the first target process, determine the time when the first target process was loaded into the CPU that was allowed to execute and the time when the first target process was last woken up.

[0145] Specifically, as can be seen from the above description, the method provided in the embodiments of this application can record the scheduling record of the process, and the scheduling record of the process can provide feedback on the time when the process is called into the CPU or called out of the CPU.

[0146] Therefore, based on the scheduling records of the first target process, the time when the first target process was loaded into a CPU that was allowed to execute and the time when the first target process was last awakened can be determined. This can then be used to calculate the duration of each scheduling delay for the first target process.

[0147] Step S302: Based on the time when the first target process is loaded into the CPU that is allowed to execute and the time when the first target process is last woken up, calculate the duration of each scheduling delay of the first target process.

[0148] Specifically, as can be seen from the above description, the above steps can obtain the time when the first target process was loaded into the CPU that was allowed to execute and the time when it was last loaded out of the CPU that was allowed to execute and was in the ready state from the scheduling record of the first target process. Based on this, the duration of each scheduling delay of the first target process can be calculated.

[0149] Wherein, the duration of each scheduling delay of the first target process is equal to the time interval between the moment the first target process is loaded into a CPU that is allowed to execute and the moment the first target process is last awakened. As can be seen from the above-described technical solution, the method provided in this application embodiment can calculate the duration of each scheduling delay of a process based on the process's scheduling record, so that the cause of the scheduling delay failure can be analyzed by analyzing the duration of each scheduling delay of the process.

[0150] As described above, the method provided in this application embodiment can create a corresponding memory circular buffer for each CPU of the kernel module of the vehicle system to store process scheduling records. When a fault or alarm occurs in the vehicle system, the scheduling records in the memory circular buffers of each CPU can be written to disk. In practical applications, by utilizing the process scheduling records stored on disk and the duration of each process scheduling delay, the method provided in this application embodiment can further determine the cause of the process scheduling delay. The following will combine... Figure 2 The process can include the following steps:

[0151] Step S401: Determine whether the scheduling delay of the first target process exceeds a preset first threshold.

[0152] Specifically, as can be seen from the above description, the method provided in the embodiments of this application can determine the duration of each scheduling delay of a process.

[0153] In practical applications, sometimes a brief scheduling delay in a process can recover on its own. However, if the scheduling delay is too long, it may be due to a fault causing the process scheduling delay.

[0154] Therefore, after determining the duration of each scheduling delay of the process, the method provided in this application embodiment can also determine whether the scheduling delay duration of the first target process exceeds a preset first threshold based on the scheduling delay duration of the first target process. If the scheduling delay duration of the first target process exceeds the preset first threshold, it indicates that the scheduling delay duration of the process exceeds the abnormal threshold, indicating that the scheduling delay of the process may be due to a system failure, and the scheduling delay of the process cannot recover on its own. Therefore, step S402 can be executed to further analyze the cause of the scheduling delay failure of the process.

[0155] The preset first threshold value can be determined based on the data processing frequency of the vehicle software.

[0156] For example, in practical applications, the fastest current data processing frequency for in-vehicle software can reach 100Hz, which means processing data once every 10ms. Therefore, the preset first threshold can be set to 10ms.

[0157] Step S402: Based on the scheduling delay duration of the first target process, determine the cause of the scheduling delay in the first target process.

[0158] Specifically, as described above, the method provided in this application embodiment can determine whether the scheduling delay of the first target process exceeds the preset first threshold. Different scheduling delays of processes can lead to different causes of failure. Therefore, after determining that the scheduling delay of the first target process exceeds the abnormal threshold, the scheduling delay records of the progress are further analyzed based on the scheduling delay of the first target process to determine the cause of the scheduling delay failure in the first target process.

[0159] As can be seen from the technical solutions described above, the method provided in this application embodiment can utilize the process scheduling records stored in the disk and the scheduling delay duration of each process. The method provided in this application embodiment can also further determine the cause of the process scheduling delay, so as to help maintenance personnel troubleshoot the fault as soon as possible.

[0160] In practical applications, the method provided in this application embodiment can utilize the process scheduling records stored on the disk. Furthermore, the method provided in this application embodiment can also monitor the running status of each process in real time, so as to promptly detect processes with excessively long running times. Next, in conjunction with... Figure 3 The process can include the following steps:

[0161] Step S501: Monitor the running status of each process in real time and determine the runtime of each process.

[0162] Specifically, as described above, the method provided in this application embodiment can utilize process scheduling records stored on the disk. Based on the process scheduling records, the method provided in this application embodiment can also monitor the running status of each process in real time and determine the runtime of each process.

[0163] The runtime of each process is equal to the time interval between when each process is loaded into the CPU for execution and when each process is removed from the CPU.

[0164] Step S502: Determine whether there is a process whose runtime exceeds a preset second threshold.

[0165] Specifically, as can be seen from the above description, the method provided in the embodiments of this application can determine the runtime of each process.

[0166] In practical applications, based on the frequency of data processing by the vehicle system software, it is generally considered that if the runtime of a process exceeds a preset second threshold, the process's runtime is excessively long. If the runtime of a process exceeds the preset second threshold, step S503 can be executed.

[0167] The preset second threshold can be set according to the frequency of data processing by the system.

[0168] For example, the preset second threshold can be set to 100ms.

[0169] Therefore, after determining the runtime of each process, it is possible to further determine whether there are any processes whose runtime exceeds a preset second threshold. This allows us to confirm whether any processes have excessively long runtimes.

[0170] Step S503: Determine the process whose runtime exceeds the preset second threshold as the second target process.

[0171] Specifically, as described above, the method provided in this application embodiment can determine the runtime of each process based on the process scheduling record, thereby determining whether the runtime of each process exceeds a preset second threshold. If the runtime of a process exceeds the preset second threshold, the process with the runtime exceeding the preset second threshold can be determined as the second target process.

[0172] The second target process can include multiple processes, and these can be considered processes with excessively long runtimes. Processes with excessively long runtimes are more prone to failure. Therefore, identifying which processes in the kernel module are excessively long-running processes allows for priority analysis of these processes when a vehicle system malfunctions, leading to a faster understanding of the cause of the failure.

[0173] Step S504: Record the call stack of the second target process in kernel mode in the system log so as to analyze the reason why the second target process runs for too long using the call stack of the second target process.

[0174] Specifically, as described above, the method provided in this application embodiment can identify processes in the kernel module whose runtime exceeds a preset second threshold as second target processes that have been running for too long. After determining which processes are the second target processes, the call stack of the second target processes in kernel mode can be recorded in the system log so as to analyze the reasons for the second target processes running for too long using the call stack of the second target processes.

[0175] As can be seen from the technical solutions described above, the method provided in this application embodiment can monitor the running status of each process in real time, so as to promptly detect processes that have been running for too long and determine which processes in the kernel module have been running for too long. When the vehicle system malfunctions, the relevant situation of the processes that have been running for too long can be analyzed first, so as to quickly understand the cause of the malfunction.

[0176] As can be seen from the technical solutions described above, the method provided in this application embodiment can monitor the running status of each process in real time and determine whether the running time of each process exceeds a preset second threshold. Next, in conjunction with... Figure 4 The process can include the following steps:

[0177] Step S601: Modify the data structure of each process in the system's kernel module and add a target field to the data structure of each process.

[0178] Specifically, in practical applications, in order to better record the runtime of each process, the data structure of each process in the system's kernel module can be modified, and a target field can be added to the data structure of each process. The target field of the process's data structure can be used to store the time point when the process state changes.

[0179] As described above, a process can be divided into three states during its execution: ready, running, and blocked. Recording the time points when each process's state transitions is crucial for calculating its runtime.

[0180] Step S602: Load the system kernel module, start a kernel timer, and set the execution conditions of the kernel timer on the hardware terminal.

[0181] Specifically, after modifying the data structure of each process in the system's kernel module, the system's kernel module can be loaded. In order to periodically monitor the running status of each process in the kernel module and determine whether the process's runtime exceeds a preset second threshold, a kernel timer can be started simultaneously, and the execution conditions of the kernel timer on the hardware terminal can be set.

[0182] The kernel timer can periodically start to monitor the running status of processes in the kernel, and the execution condition of the kernel timer can be that it will be executed once at a preset time in the context of the terminal.

[0183] Step S603: Insert the first processing function at each process switching function point. In the inserted first processing function, when the process is switched off or onto the CPU, record the time point in the target field of the process's data structure.

[0184] Specifically, as can be seen from the above description, the method provided in this application embodiment can record the time point when the state of each process changes.

[0185] When a process switch occurs, it indicates that the process may be moved off the CPU or into the CPU. Therefore, the first processing function can be inserted at the function point where each process switch occurs. In the inserted first processing function, when the process is moved off the CPU or into the CPU, the time point at that time is recorded in the target field of the process's data structure so that the recorded time point can be used to determine the runtime of each process.

[0186] Step S604: In the kernel timer processing function, determine whether the current process runtime exceeds a preset second threshold based on the record of the target field in the process's data structure.

[0187] Specifically, as described above, the method provided in this application embodiment can set a kernel timer to periodically monitor the running status of each process. Furthermore, the method can also record the moments when the process state changes. Therefore, in the kernel timer's processing function, it can determine whether the current process's runtime exceeds a preset second threshold based on the recorded target field of the process's data structure. This allows for the determination of whether the runtime of each process exceeds the preset second threshold.

[0188] As can be seen from the technical solutions described above, the method provided in this application embodiment can modify the data structure of each process in the kernel module of the system so as to monitor the running status of the process in real time, thereby determining the running time of the process and judging whether the running time of the process exceeds a preset second threshold, so as to determine which processes in the system have excessively long running times. When the vehicle system malfunctions, the relevant situation of the processes that have run for too long can be analyzed first so as to quickly understand the cause of the malfunction.

[0189] As can be seen from the technical solutions described above, the method provided in this application embodiment can determine the cause of the scheduling delay in the first target process based on the scheduling delay duration of the first target process. Next, in conjunction with... Figure 5 The process can include the following steps:

[0190] Step S701: Determine the target time period in which the scheduling delay of the first target process occurs.

[0191] Specifically, as described above, the method provided in this application embodiment can determine the scheduling delay duration of the first target process. Different scheduling delay durations lead to different causes of failure. Therefore, after the scheduling delay duration of the first target process, a target time period in which the scheduling delay of the first target process occurs can be determined. This allows for the analysis of the cause of the scheduling delay in the first target process based on the target time period in which the scheduling delay occurs.

[0192] Step S702: Determine the set of target CPUs in the system's kernel module that are allowed to execute the first target process within the target time period.

[0193] Specifically, in practical applications, the in-vehicle operating system may include a Linux system that supports the operation of multiple CPUs.

[0194] Therefore, after determining the target time period in which the scheduling delay of the first target process occurs, it is possible to further determine the target CPU set in the system's kernel module that is allowed to execute the first target process within the target time period.

[0195] In a vehicle system, multiple CPUs work simultaneously. If it is necessary to understand the cause of the scheduling delay in the first target process, it is possible to determine which CPUs are allowed to execute the first target process within the target time period, thereby identifying the relevant scheduling records of the CPU to be analyzed.

[0196] Step S703: Calculate the duration of each process using each CPU in the target CPU set within the target time period.

[0197] Specifically, after determining the set of target CPUs in the system's kernel module that are allowed to execute the first target process within the target time period, it is also necessary to count the duration of each process using each CPU within the target CPU set during the target time period, so as to further analyze the specific fault cause of the scheduling delay of the first target process.

[0198] Step S704: Based on a preset first condition, determine the cause of the scheduling delay in the first target process.

[0199] Specifically, in practical applications, after determining that the first target process has experienced a scheduling delay fault, the method provided in this application embodiment can statistically analyze the duration of each process's use of each CPU within the target CPU set during the target time period. There are many reasons why a process might experience a scheduling delay fault, and there are also many ways to analyze the causes of process scheduling faults based on process scheduling records.

[0200] Therefore, based on a preset first condition, the cause of the scheduling delay in the first target process can be determined. The preset first condition includes:

[0201] (1) The priority of each process in the target CPU set;

[0202] or,

[0203] (2) The priority of each process in the target CPU set and the duration of CPU usage;

[0204] or,

[0205] (3) The priority of each process in the target CPU set, the duration of each CPU being used, the utilization rate of each CPU in the target CPU set, and the runtime of each process in the target CPU set.

[0206] As can be seen from the technical solutions described above, the method provided in this application embodiment can analyze the process scheduling records based on the process scheduling delay duration to determine the cause of the process scheduling delay fault. This can help maintenance personnel troubleshoot the fault as quickly as possible.

[0207] As can be seen from the technical solutions described above, the method provided in this application embodiment can determine the cause of the scheduling delay in the first target process based on the priority of each process in the target CPU set. Next, in conjunction with... Figure 6 The process can include the following steps:

[0208] Step S801: Based on the priority of each process in the target CPU set, determine whether there is a process in the target CPU set with a priority higher than that of the first target process.

[0209] Specifically, as can be seen from the technical solutions described above, the method provided in this application embodiment can determine the target CPU set, in which multiple processes may exist. Each process has a different priority on each CPU.

[0210] Because only one process can be executed on a CPU at any given time, while other processes wait in a queue for CPU resources. Process priority represents the order in which processes can use CPU resources.

[0211] After determining the target CPU set, the priorities of each process in the target CPU set can be further analyzed. It can be determined whether there is a process in the target CPU set with a higher priority than the first target process. If it is determined that there is a process in the target CPU set with a higher priority than the first target process, it indicates that the first target process currently has a low priority and has not yet obtained CPU usage rights. Therefore, it also indicates that the scheduling delay of the first target process may be due to its low priority. Step S802 can then be executed.

[0212] Step S802: Determine that the cause of the scheduling delay in the first target process is that the priority settings of each process in the target CPU set are unreasonable.

[0213] Specifically, as described above, the method provided in this application embodiment can determine that there is a process in the target CPU set with a higher priority than the first target process. According to actual application requirements, the first target process should be executed at present. However, there is a process in the target CPU set with a higher priority than the first target process. Therefore, it can be determined that the cause of the scheduling delay of the first target process is that the priority settings of each process in the target CPU set are unreasonable.

[0214] As can be seen from the technical solutions described above, the method provided in this application embodiment can determine the cause of the scheduling delay in the first target process based on the priority of each process in the target CPU set. When it is determined that there is a process in the target CPU set with a higher priority than the first target process, it can be determined that the cause of the scheduling delay in the first target process is that the priority settings of each process in the target CPU set are unreasonable. This allows for the determination of the cause of the scheduling delay, helping maintenance personnel to troubleshoot the problem as quickly as possible.

[0215] As can be seen from the technical solutions described above, the method provided in this application embodiment can determine the cause of the scheduling delay in the first target process based on the priority of each process in the target CPU set and the duration of each CPU being used. Next, in conjunction with... Figure 7 The process can include the following steps:

[0216] Step S901: Based on the priority of each process in the target CPU set, determine whether there is a process in the target CPU set with a priority higher than that of the first target process.

[0217] Specifically, as can be seen from the technical solutions described above, the method provided in this application embodiment can determine the target CPU set, in which multiple processes may exist. Each process has a different priority on each CPU.

[0218] Because only one process can be executed on a CPU at any given time, while other processes wait in a queue for CPU resources. Process priority represents the order in which processes can use CPU resources.

[0219] After determining the target CPU set, the priorities of each process within the target CPU set can be further analyzed. It can be determined whether there are processes in the target CPU set with a higher priority than the first target process. If no process with a higher priority is found, it indicates that at the current moment, there may be a process in the target CPU set whose CPU usage time exceeds a preset third threshold. If there is a process in the target CPU set whose CPU usage time exceeds the preset third threshold, it indicates that this process is occupying the CPU for too long, which may be the cause of the scheduling delay in the first target process.

[0220] If there is no process in the target CPU set with a higher priority than the first target process, then step S902 can be further executed.

[0221] The preset third threshold can be set by referring to the CPU utilization rate of a certain process within the target time period in which the scheduling delay occurs. The formula for calculating the CPU utilization rate of a certain process within the target time period in which the scheduling delay occurs can include the following:

[0222] The utilization rate of a process on a CPU is equal to the total time that process uses the CPU divided by the duration of the target time period in which the scheduling delay occurs.

[0223] For example, the preset third threshold can be set to 99% of the total time a single process uses a CPU.

[0224] If a single process in the target CPU set uses 99% of the total CPU time, it indicates that the time spent on the CPU by that single process is too long, which may be the reason for the scheduling delay of the first target process.

[0225] Step S902: Determine whether there is a process in the target CPU set whose single CPU has been used for a duration exceeding a preset third threshold.

[0226] Specifically, as described above, the method provided in this application embodiment can determine whether there is a process in the target CPU set whose single CPU usage time exceeds a preset third threshold. If it can be determined that there is a process in the target CPU set whose single CPU usage time exceeds the preset third threshold, it can be determined that the excessive CPU usage time of a single process may have caused the scheduling delay of the first target process.

[0227] Therefore, the cause of the scheduling delay in the first target process can be analyzed by determining whether there is a process in the target CPU set whose single CPU usage time exceeds a preset third threshold.

[0228] If it is determined that there is a process in the target CPU set whose single CPU usage time exceeds the preset third threshold, then step S903 can be executed to further analyze the cause of the scheduling delay in the first target process.

[0229] Step S903: Check the running records of processes in the target CPU set whose running time exceeds a preset second threshold, determine the processes in the target CPU set whose running time exceeds the preset second threshold as second target processes, and determine the cause of the scheduling delay of the first target process based on the running records of the second target processes.

[0230] Specifically, after determining that there is a process in the target CPU set whose CPU usage time exceeds the preset third threshold, it can be basically determined that there may be processes with excessively long runtimes in the target CPU set. Therefore, the execution records of processes in the target CPU set whose runtime exceeds the preset second threshold can be further examined to determine the processes in the target CPU set whose runtime exceeds the preset second threshold as the second target processes.

[0231] As described above, in practical applications, based on the frequency of data processing by the vehicle system software, a process is generally considered to have excessively long runtime when its runtime exceeds a preset second threshold. Processes with excessively long runtimes are more prone to failure.

[0232] The preset second threshold can be set according to the frequency of data processing by the system.

[0233] For example, the preset second threshold can be set to 100ms.

[0234] A process that runs for too long may occupy CPU time, potentially preventing another process from being scheduled in a timely manner, thus causing scheduling delays in that process. Therefore, by analyzing the call stack of the second target process based on its execution log, the reason for its excessive execution time can be determined. This allows us to pinpoint the cause of the scheduling delay in the first target process.

[0235] As can be seen from the technical solutions described above, the method provided in this application embodiment can determine the cause of the scheduling delay of the first target process by considering the priority of each process in the target CPU set and the usage time of each CPU. When it is determined that there is no process in the target CPU set with a higher priority than the first target process, the running records of processes in the target CPU set whose running time exceeds a preset second threshold can be further checked to determine the process in the target CPU set whose running time exceeds the preset second threshold as the second target process. Based on the running records of the second target process, the cause of the scheduling delay of the first target process can be determined, so as to help maintenance personnel troubleshoot the fault as soon as possible.

[0236] As can be seen from the above-described technical solutions, the method provided in this application embodiment can determine the cause of the scheduling delay in the first target process based on the priority of each process in the target CPU set, the duration of each CPU being used, the utilization rate of each CPU in the target CPU set, and the runtime of each process in the target CPU set. Next, in conjunction with... Figure 8 The process can include the following steps:

[0237] Step S111: Based on the priority of each process in the target CPU set, determine whether there is a process in the target CPU set with a priority higher than that of the first target process.

[0238] Specifically, this step corresponds to step S901 above, and can be referred to the description of step S901 above, which will not be repeated here.

[0239] Step S112: Determine whether there is a process in the target CPU set whose single CPU has been used for a duration exceeding a preset third threshold.

[0240] Specifically, this step corresponds to step S902 above, and can be referred to the description of step S902 above, which will not be repeated here. If there is no process in the target CPU set where the usage time of a single CPU exceeds the preset third threshold, then it is possible to further check whether there are some CPUs in the target CPU set with uneven utilization, some CPUs with excessively high utilization, and some CPUs with excessively low utilization.

[0241] Step S113: Determine whether there are cases in the target CPU set where the utilization rate of some CPUs exceeds the preset fourth threshold and the utilization rate of some CPUs is lower than the preset fourth threshold.

[0242] Specifically, as described above, if this application can determine that there is no single CPU in the target CPU set whose usage time exceeds the preset third threshold process, it can further check whether there are some CPUs in the target CPU set with uneven usage, some CPUs with excessively high usage, and some CPUs with excessively low usage.

[0243] Therefore, it can be further determined whether there are cases in the target CPU set where the utilization rate of some CPUs exceeds the preset fourth threshold, and the utilization rate of some CPUs is lower than the preset fourth threshold.

[0244] Among these, research suggests that the fourth threshold can be set to 50%.

[0245] If there are instances in the target CPU set where some CPUs have a utilization rate exceeding 50% and others have a utilization rate below 50%, it indicates an uneven distribution of CPU usage rights within the target CPU set, resulting in some CPU resources being over-utilized and others under-utilized.

[0246] Therefore, if it is determined that there are some CPUs in the target CPU set whose utilization exceeds a preset fourth threshold, and some CPUs whose utilization is below the preset fourth threshold, then step S114 can be executed to further determine the cause of the scheduling delay in the first target process.

[0247] Step S114: Determine that the cause of the scheduling delay in the first target process is that the grouping of each CPU in the target CPU set is unreasonable, resulting in uneven use of each CPU.

[0248] Specifically, as can be seen from the above description, if it is determined that there are some CPUs in the target CPU set whose utilization rate exceeds the preset fourth threshold and some CPUs whose utilization rate is lower than the preset fourth threshold, it indicates that the CPU resource allocation of the target CPU set is uneven at the current moment, which may cause a process scheduling delay fault.

[0249] Therefore, it can be determined that the cause of the scheduling delay in the first target process is that the grouping of each CPU in the target CPU set is unreasonable, resulting in uneven use of each CPU.

[0250] As can be seen from the technical solutions described above, the method provided in this application embodiment can analyze whether there are some CPUs in the target CPU set whose utilization rate exceeds the preset fourth threshold and some CPUs whose utilization rate is lower than the preset fourth threshold. If it is determined that there are some CPUs in the target CPU set whose utilization rate exceeds the preset fourth threshold and some CPUs whose utilization rate is lower than the preset fourth threshold, then it can be determined that the cause of the scheduling delay of the first target process is that the grouping of each CPU in the target CPU set is unreasonable, resulting in uneven use of each CPU, so as to help maintenance personnel troubleshoot the fault as soon as possible.

[0251] As can be seen from the above-described technical solutions, the method provided in this application embodiment can determine the cause of the scheduling delay in the first target process based on the priority of each process in the target CPU set, the duration of each CPU being used, the utilization rate of each CPU in the target CPU set, and the runtime of each process in the target CPU set. Next, in conjunction with... Figure 9 The process can include the following steps:

[0252] Step S121: Based on the priority of each process in the target CPU set, determine whether there is a process in the target CPU set with a priority higher than that of the first target process.

[0253] Specifically, this step corresponds to step S901 above, and can be referred to the description of step S901 above, which will not be repeated here.

[0254] Step S122: If there is no process in the target CPU set with a priority higher than that of the first target process, then determine whether there is a process in the target CPU set whose single CPU usage time exceeds a preset third threshold.

[0255] Specifically, this step corresponds to step S902 above, and you can refer to the description of step S902 above, which will not be repeated here.

[0256] If there is no single CPU in the target CPU set that has been used for a duration exceeding the preset third threshold, then step S123 can be executed.

[0257] Step S123: Determine whether there are cases in the target CPU set where the utilization rate of some CPUs exceeds the preset fourth threshold and the utilization rate of some CPUs is lower than the preset fourth threshold.

[0258] Specifically, this step corresponds to step S113 above, and can be referred to the description of step S113 above, which will not be repeated here.

[0259] If it is determined that there are no cases in the target CPU set where the utilization rate of some CPUs exceeds the preset fourth threshold and the utilization rate of some CPUs is lower than the preset fourth threshold, then it indicates that the process scheduling failure may not be caused by the unreasonable grouping of the CPUs in the target CPU set leading to uneven use of the CPUs.

[0260] Therefore, it is possible to further analyze and determine whether the utilization rate of any CPU in the target CPU set exceeds a preset fifth threshold. This allows for analysis of whether each CPU in the target CPU set is fully loaded.

[0261] Step S124: Determine whether the utilization rate of any CPU in the target CPU set exceeds a preset fifth threshold.

[0262] Specifically, if it is determined that there are no cases in the target CPU set where the utilization rate of some CPUs exceeds the preset fourth threshold and the utilization rate of some CPUs is lower than the preset fourth threshold, then it indicates that the process scheduling failure may not be caused by the unreasonable grouping of the CPUs in the target CPU set leading to uneven use of the CPUs.

[0263] Further analysis can be conducted to determine whether the process scheduling delay is caused by the full load of each CPU in the target CPU set.

[0264] The preset fourth threshold can be set using the following formula:

[0265] The preset fourth threshold is equal to the total duration of non-idle processes using the CPU divided by the duration of the target time period in which the scheduling delay occurs.

[0266] Studies have shown that when the utilization rate of a CPU reaches 90%, the performance of each CPU decreases slightly, and process scheduling delays may occur.

[0267] Therefore, the preset fifth threshold can be set to 90%. If it is determined that the utilization rate of any CPU in the target CPU set exceeds 90%, it indicates that each CPU in the target CPU set is fully loaded, which may cause process failure.

[0268] Step S125: It is determined that the cause of the scheduling delay in the first target process is that all CPUs in the target CPU set are fully loaded, and it is necessary to consider expanding the number of CPUs.

[0269] Specifically, as described above, if it is determined that the utilization rate of any CPU in the target CPU set exceeds the preset fifth threshold, it indicates that the CPUs in the target CPU set are fully loaded, which may lead to process failure.

[0270] Therefore, when it is determined that the utilization rate of any CPU in the target CPU set exceeds the preset fifth threshold, it can be determined that the cause of the scheduling delay in the first target process is that each CPU in the target CPU set is fully loaded, and it is necessary to consider expanding the number of CPUs.

[0271] As can be seen from the above-described technical solutions, the method provided in this application embodiment can analyze whether the utilization rate of any CPU in the target CPU set exceeds a preset fifth threshold. If it is determined that the utilization rate of any CPU in the target CPU set exceeds the preset fifth threshold, it can be determined that the cause of the scheduling delay of the first target process is that each CPU in the target CPU set is fully loaded, and it is necessary to consider expanding the number of CPUs so as to help maintenance personnel troubleshoot the fault as soon as possible.

[0272] As can be seen from the above-described technical solutions, the method provided in this application embodiment can determine the cause of the scheduling delay in the first target process based on the priority of each process in the target CPU set, the duration of each CPU being used, the utilization rate of each CPU in the target CPU set, and the runtime of each process in the target CPU set. Next, in conjunction with... Figure 10 The process can include the following steps:

[0273] Step S131: Based on the priority of each process in the target CPU set, determine whether there is a process in the target CPU set with a priority higher than that of the first target process.

[0274] Specifically, this step corresponds to step S901 above, and can be referred to the description of step S901 above, which will not be repeated here.

[0275] Step S132: Determine whether there is a process in the target CPU set whose single CPU usage time exceeds a preset third threshold.

[0276] Specifically, this step corresponds to step S902 above, and you can refer to the description of step S902 above, which will not be repeated here.

[0277] Step S133: Determine whether there are cases in the target CPU set where the utilization rate of some CPUs exceeds the preset fourth threshold and the utilization rate of some CPUs is lower than the preset fourth threshold.

[0278] Specifically, this step corresponds to step S113 above, and can be referred to the description of step S113 above, which will not be repeated here.

[0279] Step S134: Determine whether the utilization rate of any CPU in the target CPU set exceeds a preset fifth threshold.

[0280] Specifically, this step corresponds to step S124 above, and can be referred to the description of step S124 above, which will not be repeated here.

[0281] If there are CPUs in the target CPU set whose utilization rate does not exceed the preset fifth threshold, it means that the scheduling delay of the process is not caused by the fact that each CPU in the target CPU set is fully loaded.

[0282] The scheduling delay may be caused by untimely task migration or a defect in the scheduler. Therefore, step S135 can be executed.

[0283] Step S135: Determine that the cause of the scheduling delay in the first target process is untimely task migration or a defect in the scheduler.

[0284] Specifically, as described above, the embodiments of this application can determine that there are CPUs in the target CPU set whose utilization rate does not exceed the preset fifth threshold, indicating that there are still usable CPUs in the target CPU set. Therefore, it can be concluded that the scheduling delay caused by the process is not because all CPUs in the target CPU set are fully loaded.

[0285] Therefore, it can be determined that the cause of the scheduling delay in the first target process is either untimely task migration or a defect in the scheduler.

[0286] As can be seen from the above-described technical solutions, the method provided in this application embodiment can analyze whether the utilization rate of any CPU in the target CPU set exceeds a preset fifth threshold. If it is determined that there is a CPU in the target CPU set whose utilization rate does not exceed the preset fifth threshold, then it can be determined that the cause of the scheduling delay of the first target process is untimely task migration or a defect in the scheduler, so as to help maintenance personnel troubleshoot the fault as soon as possible.

[0287] The following describes the vehicle system fault detection device provided in the embodiments of this application. The vehicle system fault detection device described below and the vehicle system fault detection method described above can be referred to in correspondence.

[0288] See Figure 11 , Figure 11 This is a schematic diagram of the structure of a vehicle system fault detection device disclosed in an embodiment of this application.

[0289] like Figure 11 As shown, the vehicle-mounted system fault detection device may include:

[0290] Loading module unit 101 is used to load the kernel module of the vehicle system;

[0291] The buffer creation unit 102 is used to create a corresponding memory circular buffer for each CPU in the kernel module, wherein the memory circular buffer is used to cyclically store the scheduling records of the corresponding CPU;

[0292] The first function insertion unit 103 is used to insert a custom first processing function at the function point where the first target process is switched and woken up.

[0293] The first editing unit 104 is used to call the first processing function when the first target process is switched and woken up, and write the scheduling record of calling the first processing function and calling the first target process into the memory ring buffer corresponding to the CPU of the first target process.

[0294] The second editing unit 105 is used to notify the kernel module to write the records in the memory ring buffer of each CPU to the disk when the vehicle system malfunctions or alarms, so as to detect the malfunction of the vehicle system.

[0295] As can be seen from the above-described technical solutions, the apparatus provided in this application embodiment can utilize the loading module unit 101 to load the kernel module of the vehicle system; and utilize the buffer creation unit 102 to create a corresponding memory circular buffer for each CPU in the kernel module. The memory circular buffer is used to cyclically store the scheduling records of the corresponding CPUs, so that when a fault occurs in the vehicle system, the CPU scheduling records can be obtained from the memory circular buffer to analyze the cause of the vehicle system fault. Simultaneously, the first function insertion unit 103 can be used to insert a custom first processing function at the function point where the first target process switches and wakes up. When the first target process switches and wakes up, the first editing unit 104 can be used to call the first processing function, and the scheduling record of calling the first processing function and the first target process can be written into the memory circular buffer corresponding to the CPU of the first target process, so that the call record of the first target process can be recorded. When a fault or alarm occurs in the vehicle system, the second editing unit 105 can be used to notify the kernel module to write the scheduling records in the memory circular buffers of each CPU to the disk for detecting faults in the vehicle system. Therefore, the device provided in this application embodiment can determine the specific reasons for the scheduling delay of a process based on the process scheduling record, so as to help maintenance personnel troubleshoot in a timely manner and ensure that the vehicle system can operate normally.

[0296] The specific processing flow of each unit included in the above-mentioned vehicle system fault detection device can be found in the relevant introduction of the vehicle system fault detection method section above, and will not be repeated here.

[0297] The vehicle system fault detection device provided in this application embodiment can be applied to vehicle system fault detection equipment, such as terminals: mobile phones, computers, etc. Optionally, Figure 12 The hardware structure block diagram of the vehicle system fault detection device is shown. (Refer to...) Figure 12 The hardware structure of the vehicle system fault detection device may include: at least one processor 1, at least one communication interface 2, at least one memory 3, and at least one communication bus 4.

[0298] In this embodiment, the number of processor 1, communication interface 2, memory 3, and communication bus 4 is at least one, and processor 1, communication interface 2, and memory 3 communicate with each other through communication bus 4.

[0299] Processor 1 may be a central processing unit (CPU), an application-specific integrated circuit (ASIC), or one or more integrated circuits configured to implement the embodiments of this application.

[0300] Memory 3 may include high-speed RAM, and may also include non-volatile memory, such as at least one disk storage device;

[0301] The memory stores a program, and the processor can call the program stored in the memory. The program is used to implement the various processing steps in the aforementioned terminal vehicle system fault detection scheme.

[0302] This application embodiment also provides a readable storage medium that can store a program suitable for processor execution, the program being used to: implement the various processing flows of the aforementioned terminal in the vehicle system fault detection scheme.

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

[0304] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. The same or similar parts between the various embodiments can be referred to each other.

[0305] The above description of the disclosed embodiments enables those skilled in the art to make or use this application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this application. Various embodiments can be combined with each other. Therefore, this application is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A method for detecting faults in a vehicle-mounted system, characterized in that, include: Load the kernel module of the vehicle system; The processes created by the kernel module according to requirements are managed by the kernel module. In the kernel module, a corresponding memory circular buffer is created for each CPU, wherein the memory circular buffer is used to cyclically store the scheduling records of the corresponding CPU; Insert a custom first processing function at the function point where the first target process switches and is woken up; When the first target process is switched or woken up, the first processing function is invoked, and the scheduling record of the invocation of the first processing function and the invocation of the first target process is written into the memory circular buffer corresponding to the CPU of the first target process; wherein, the first processing function is used to record the scheduling record when the first target process is switched or woken up; When a fault or alarm occurs in the vehicle system, the kernel module is notified to write the scheduling records in the memory ring buffer of each CPU to the disk for the purpose of detecting the fault in the vehicle system. The method also includes: Based on the scheduling record of the first target process, calculate the duration of each scheduling delay of the first target process; determine whether the scheduling delay duration of the first target process exceeds a preset first threshold; if the scheduling delay duration of the first target process exceeds the preset first threshold, determine the cause of the scheduling delay failure of the first target process based on the scheduling delay duration of the first target process. The step of determining the cause of the scheduling delay in the first target process based on the scheduling delay duration includes: Determine the target time period in which the scheduling delay of the first target process occurs; determine the target CPU set in the system's kernel module that is allowed to execute the first target process within the target time period; count the duration of each process using each CPU within the target CPU set within the target time period; and determine the cause of the scheduling delay of the first target process based on a preset first condition. The preset first condition includes: the priority of each process in the target CPU set; or, the priority of each process in the target CPU set and the usage time of each CPU; or, the priority of each process in the target CPU set, the usage time of each CPU, the utilization rate of each CPU in the target CPU set, and the runtime of each process in the target CPU set; the causes of the fault include: the priority setting of each process in the target CPU set is unreasonable; or, the runtime of the second target process exceeds the preset second threshold; or, the grouping of each CPU in the target CPU set is unreasonable, resulting in uneven use of each CPU; or, each CPU in the target CPU set is fully loaded, and it is necessary to consider expanding the number of CPUs; or, the task migration is not timely or the scheduler has defects.

2. The method according to claim 1, characterized in that, The calculation of the duration of each scheduling delay for the first target process based on the scheduling record of the first target process includes: Based on the scheduling record of the first target process, determine the time when the first target process was loaded into a CPU that was allowed to execute, the time when it was last loaded out of a CPU that was allowed to execute and was in a ready state, or the time when the first target process was last woken up. Based on the time when the first target process is loaded into the CPU that is allowed to execute and the time when it was last loaded out of the CPU that is allowed to execute and is in the ready state, the duration of each scheduling delay of the first target process is calculated, wherein the duration of each scheduling delay of the first target process is equal to the time interval between the time when the first target process is loaded into the CPU that is allowed to execute and the time when the first target process was last loaded out of the CPU that is allowed to execute and is in the ready state. Alternatively, based on the time when the first target process is loaded into the CPU that is allowed to execute and the time when the first target process is last woken up, the duration of each scheduling delay of the first target process is calculated, wherein the duration of each scheduling delay of the first target process is equal to the time interval between the time when the first target process is loaded into the CPU that is allowed to execute and the time when the first target process is last woken up.

3. The method according to claim 1, characterized in that, The method also includes: The runtime of each process is monitored in real time to determine the runtime of each process. The runtime of each process is equal to the time interval between when each process is loaded into the CPU for execution and when each process is loaded out of the CPU. Determine if there are any processes whose runtime exceeds a preset second threshold; If there is a process whose runtime exceeds the preset second threshold, then the process whose runtime exceeds the preset second threshold is determined as the second target process; Record the call stack of the second target process in kernel mode in the system log so as to analyze the reason why the second target process runs for too long using the call stack of the second target process.

4. The method according to claim 3, characterized in that, The step of determining whether the runtime of each process exceeds a preset second threshold includes: Modify the data structure of each process in the system's kernel module, and add a target field to the data structure of each process. The target field of the process's data structure is used to store the time point when the process state changes. Load the system's kernel module, start a kernel timer, and set the execution conditions of the kernel timer on the hardware terminal; Insert the first processing function at each process switching function point. In the inserted first processing function, when the process is switched off the CPU or switched into the CPU, record the time point at that time in the target field of the process's data structure. In the kernel timer's processing function, the runtime of the current process is determined based on the record of the target field in the process's data structure to see if it exceeds a preset second threshold.

5. The method according to claim 1, characterized in that, The step of determining the cause of the scheduling delay in the first target process based on the priority of each process in the target CPU set includes: Based on the priority of each process in the target CPU set, determine whether there is a process in the target CPU set with a higher priority than the first target process; If there is a process in the target CPU set with a higher priority than the first target process, then the cause of the scheduling delay in the first target process is determined to be that the priority settings of each process in the target CPU set are unreasonable.

6. The method according to claim 1, characterized in that, The step of determining the cause of the scheduling delay in the first target process based on the priority of each process in the target CPU set and the duration of CPU usage includes: Based on the priority of each process in the target CPU set, determine whether there is a process in the target CPU set with a higher priority than the first target process; If there is no process in the target CPU set with a priority higher than that of the first target process, then it is determined whether there is a process in the target CPU set whose CPU usage time exceeds a preset third threshold. If there is a process in the target CPU set whose CPU usage time exceeds the preset third threshold, then check the running records of the processes in the target CPU set whose running time exceeds the preset second threshold, determine the processes in the target CPU set whose running time exceeds the preset second threshold as the second target processes, and determine the cause of the scheduling delay in the first target process based on the running records of the second target processes.

7. The method according to claim 1, characterized in that, The step of determining the cause of the scheduling delay in the first target process based on the priority of each process in the target CPU set, the duration of each CPU usage, the utilization rate of each CPU in the target CPU set, and the runtime of each process in the target CPU set includes: Based on the priority of each process in the target CPU set, determine whether there is a process in the target CPU set with a higher priority than the first target process; If there is no process in the target CPU set with a priority higher than that of the first target process, then it is determined whether there is a process in the target CPU set whose CPU usage time exceeds a preset third threshold. If there is no process in the target CPU set where the duration of a single CPU used exceeds the preset third threshold, then it is determined whether there are cases in the target CPU set where the utilization rate of some CPUs exceeds the preset fourth threshold and the utilization rate of some CPUs is lower than the preset fourth threshold. If some CPUs in the target CPU set have a utilization rate exceeding the preset fourth threshold, while some CPUs have a utilization rate below the preset fourth threshold, then the cause of the scheduling delay in the first target process is determined to be that the grouping of the CPUs in the target CPU set is unreasonable, resulting in uneven use of the CPUs.

8. The method according to claim 1, characterized in that, The step of determining the cause of the scheduling delay in the first target process based on the priority of each process in the target CPU set, the duration of each CPU usage, the utilization rate of each CPU in the target CPU set, and the runtime of each process in the target CPU set includes: Based on the priority of each process in the target CPU set, determine whether there is a process in the target CPU set with a higher priority than the first target process; If there is no process in the target CPU set with a priority higher than that of the first target process, then it is determined whether there is a process in the target CPU set whose CPU usage time exceeds a preset third threshold. If there is no process in the target CPU set where the duration of a single CPU used exceeds the preset third threshold, then it is determined whether there are cases in the target CPU set where the utilization rate of some CPUs exceeds the preset fourth threshold and the utilization rate of some CPUs is lower than the preset fourth threshold. If there is no situation in the target CPU set where the utilization rate of some CPUs exceeds the preset fourth threshold and the utilization rate of some CPUs is lower than the preset fourth threshold, then it is determined whether the utilization rate of any CPU in the target CPU set exceeds the preset fifth threshold. If the utilization rate of any CPU in the target CPU set exceeds the preset fifth threshold, then the cause of the scheduling delay in the first target process is determined to be that all CPUs in the target CPU set are fully loaded, and it is necessary to consider expanding the number of CPUs.

9. The method according to claim 1, characterized in that, The step of determining the cause of the scheduling delay in the first target process based on the priority of each process in the target CPU set, the duration of each CPU usage, the utilization rate of each CPU in the target CPU set, and the runtime of each process in the target CPU set includes: Based on the priority of each process in the target CPU set, determine whether there is a process in the target CPU set with a higher priority than the first target process; If there is no process in the target CPU set with a priority higher than that of the first target process, then it is determined whether there is a process in the target CPU set whose CPU usage time exceeds a preset third threshold. If there is no process in the target CPU set where the duration of a single CPU used exceeds the preset third threshold, then it is determined whether there are cases in the target CPU set where the utilization rate of some CPUs exceeds the preset fourth threshold and the utilization rate of some CPUs is lower than the preset fourth threshold. If there is no situation in the target CPU set where the utilization rate of some CPUs exceeds the preset fourth threshold and the utilization rate of some CPUs is lower than the preset fourth threshold, then it is determined whether the utilization rate of any CPU in the target CPU set exceeds the preset fifth threshold. If there is a CPU in the target CPU set whose utilization rate does not exceed the preset fifth threshold, then the cause of the scheduling delay in the first target process is determined to be untimely task migration or a defect in the scheduler.

10. A vehicle-mounted system fault detection device, characterized in that, include: The module loading unit is used to load the kernel module of the vehicle system; The processes created by the kernel module according to requirements are managed by the kernel module. A buffer creation unit is used to create a corresponding memory circular buffer for each CPU in the kernel module, wherein the memory circular buffer is used to cyclically store the scheduling records of the corresponding CPU; The first function insertion unit is used to insert a custom first processing function at the function point where the first target process is switched and woken up. The first editing unit is used to call the first processing function when the first target process is switched or woken up, and write the call to the first processing function and the scheduling record of the call to the first target process into the memory circular buffer corresponding to the CPU of the first target process; wherein, the first processing function is used to record the scheduling record when the first target process is switched or woken up; The second editing unit is used to notify the kernel module to write the records in the memory circular buffer of each CPU to the disk when the vehicle system malfunctions or alarms, so as to detect the malfunction of the vehicle system; it also includes: calculating the duration of each scheduling delay of the first target process based on the scheduling record of the first target process; determining whether the scheduling delay duration of the first target process exceeds a preset first threshold; if the scheduling delay duration of the first target process exceeds the preset first threshold, determining the cause of the scheduling delay of the first target process based on the scheduling delay duration of the first target process; The step of determining the cause of the scheduling delay of the first target process based on the scheduling delay duration of the first target process includes: determining the target time period in which the scheduling delay of the first target process occurs; determining the target CPU set in the system's kernel module that is allowed to execute the first target process within the target time period; counting the duration of each process using each CPU within the target CPU set within the target time period; and determining the cause of the scheduling delay of the first target process based on a preset first condition. The preset first condition includes: the priority of each process in the target CPU set; or, the priority of each process in the target CPU set and the usage time of each CPU; or, the priority of each process in the target CPU set, the usage time of each CPU, the utilization rate of each CPU in the target CPU set, and the runtime of each process in the target CPU set; the causes of the fault include: the priority setting of each process in the target CPU set is unreasonable; or, the runtime of the second target process exceeds the preset second threshold; or, the grouping of each CPU in the target CPU set is unreasonable, resulting in uneven use of each CPU; or, each CPU in the target CPU set is fully loaded, and it is necessary to consider expanding the number of CPUs; or, the task migration is not timely or the scheduler has defects.

11. A vehicle-mounted system fault detection device, characterized in that, include: One or more processors, and memory; The memory stores computer-readable instructions, which, when executed by the one or more processors, implement the steps of the vehicle system fault detection method as described in any one of claims 1 to 9.

12. A readable storage medium, characterized in that: The readable storage medium stores computer-readable instructions, which, when executed by one or more processors, cause the one or more processors to perform the steps of the vehicle system fault detection method as described in any one of claims 1 to 9.

Images