A time delay diagnosis method and device for a vehicle-mounted system, a medium and an electronic device

Abstract

The application discloses a kind of time delay diagnosis method, device, medium and electronic equipment of vehicle-mounted system.Therein method includes: in response to the start of vehicle-mounted system, determine to be monitored thread;In the running process of the to-be-monitored thread, the to-be-monitored thread is monitored to simulate page fault, and in the case where the to-be-monitored thread exists simulated page fault phenomenon, determine page fault type and page fault processing time, form page fault management data;According to the page fault management data, each to-be-monitored thread is diagnosed for time delay, and determines time delay diagnosis result.Thread processing process is diagnosed for time delay reason, it is advantageous to optimize the running process of thread based on time delay diagnosis result, further optimize the operation of vehicle-mounted system, ensure that vehicle is normally operated in form process.

Description

Technical Field

[0001] This invention relates to the field of data processing technology, and in particular to a delay diagnosis method, device, medium, and electronic equipment for vehicle systems. Background Technology

[0002] Autonomous driving systems have extremely high latency requirements during operation, especially the time taken for critical processing flows must not fluctuate significantly. Among the many potential factors affecting latency, the time spent handling memory page faults caused by program access to memory is one of the key factors.

[0003] Effective diagnostic analysis of the time consumption of critical processing flows requires effective measurement of the time consumption caused by memory access page faults in order to determine the main cause of the time consumption, which is conducive to targeted optimization of the time consumption. Summary of the Invention

[0004] This invention provides a method, apparatus, medium, and electronic device for diagnosing latency in an in-vehicle system, which records and diagnoses the time consumed by memory access faults during the autonomous driving process of a vehicle, and facilitates targeted optimization of memory access faults.

[0005] According to one aspect of the present invention, a delay diagnosis method for an in-vehicle system is provided, comprising:

[0006] In response to the startup of the vehicle system, determine the thread to be monitored;

[0007] During the operation of the thread to be monitored, page faults are monitored for the thread to be monitored, and if page faults occur in the thread to be monitored, the page fault type and page fault processing time are determined to form page fault management data.

[0008] Based on the page fault management data, latency diagnosis is performed on each of the monitored threads to determine the latency diagnosis result.

[0009] Optionally, when a page fault occurs in the thread under monitoring, determining the page fault type and page fault processing time to form page fault management data includes:

[0010] If a page fault occurs in the thread to be monitored, the page fault handling function is called, and page fault handling is performed based on the page fault handling function.

[0011] Record the start and end timestamps of the page fault handling function, and determine the page fault handling time based on the start and end timestamps;

[0012] Based on the input parameters and processing results of the page fault handling function, the page fault type is determined.

[0013] Optionally, the method further includes:

[0014] Replace the page fault handling function with a calling function, and set the function address of the page fault handling function in a preset variable;

[0015] Accordingly, the invocation of the page fault handling function includes:

[0016] The function call function reads the address of the page fault handling function from the preset variables and calls the page fault handling function based on the function address.

[0017] Optionally, the page fault management data is in the form of a structure tree, including the thread identifier of each thread to be monitored and the number of page faults, page fault types, and page fault processing time of each thread in each monitoring period.

[0018] Optionally, the step of performing latency diagnosis on each of the monitored threads based on the page fault management data and determining the latency diagnosis result includes:

[0019] Determine the processing time of the thread to be monitored for any processing path, and determine whether the thread to be diagnosed meets the latency diagnosis conditions based on the processing time;

[0020] If so, then determine whether the total time spent on page fault processing for each page fault type exceeds the corresponding latency threshold during the execution of the thread to be diagnosed.

[0021] If the total time spent on page fault processing for any page fault type exceeds the corresponding latency threshold, then the simulated memory page fault phenomenon is determined to be the main cause of latency.

[0022] Optionally, after determining the page fault type and page fault processing time, the method further includes:

[0023] Page fault information for each thread to be monitored is recorded according to the recording rules to form a time consumption log;

[0024] Accordingly, if the page fault processing time for any page fault type exceeds the corresponding latency threshold, the method further includes:

[0025] From the time-consuming log, sample the logs corresponding to the page fault type, visualize the sampled logs, and / or determine optimizable points based on the sampled logs.

[0026] Optionally, the step of recording page fault information for each of the monitored threads according to recording rules to form a time-consuming log includes:

[0027] If the page fault processing time exceeds the first preset threshold, the current page fault information is recorded.

[0028] If the page fault processing time is less than the first preset threshold, the ratio of the number of page faults in the current monitoring period to the number of page faults in the previous monitoring period is determined, and the sampling record ratio is determined according to the ratio. The current page fault information is then recorded according to the sampling record ratio.

[0029] According to another aspect of the present invention, a time delay diagnostic device for an in-vehicle system is provided, comprising:

[0030] The thread to be monitored module is used to determine the thread to be monitored in response to the startup of the vehicle system;

[0031] The memory access page fault monitoring module is used to monitor the memory access page fault during the operation of the thread to be monitored, and to determine the page fault type and page fault processing time when the thread to be monitored has a memory access page fault, thereby forming page fault management data.

[0032] The latency diagnosis module is used to perform latency diagnosis on each of the monitored threads based on the page fault management data and determine the latency diagnosis result.

[0033] According to another aspect of the present invention, an electronic device is provided, the electronic device comprising:

[0034] At least one processor; and

[0035] A memory communicatively connected to the at least one processor; wherein,

[0036] The memory stores a computer program that can be executed by the at least one processor, which enables the at least one processor to perform the time delay diagnosis method for the vehicle system according to any embodiment of the present invention.

[0037] According to another aspect of the present invention, a computer-readable storage medium is provided, the computer-readable storage medium storing computer instructions for causing a processor to execute and implement the delay diagnosis method of the vehicle system according to any embodiment of the present invention.

[0038] The technical solution of this invention monitors the memory access page fault phenomenon of the thread during thread operation and records the page fault processing time and page fault type. This facilitates the diagnosis of the cause of latency during thread processing, and helps to optimize the thread operation process based on the latency diagnosis results. This further optimizes the operation of the vehicle system and ensures the normal operation of the vehicle during operation.

[0039] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of the present invention, nor is it intended to limit the scope of the invention. Other features of the invention will become readily apparent from the following description. Attached Figure Description

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

[0041] Figure 1 This is a flowchart of a time delay diagnosis method for an in-vehicle system provided in an embodiment of the present invention;

[0042] Figure 2 This is a schematic diagram of the structure of a time delay diagnostic device for an in-vehicle system provided in an embodiment of the present invention;

[0043] Figure 3 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention. Detailed Implementation

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

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

[0046] Figure 1This is a flowchart of a latency diagnosis method for an in-vehicle system provided by an embodiment of the present invention. This embodiment is applicable to monitoring memory page faults during thread execution and analyzing and diagnosing the time consumption caused by memory page faults. This method can be executed by a latency diagnosis device for the in-vehicle system, which can be implemented in hardware and / or software and can be configured in electronic devices such as in-vehicle systems. Figure 1 As shown, the method includes:

[0047] S110, In response to the startup of the vehicle system, determine the thread to be monitored.

[0048] S120. During the operation of the thread to be monitored, page faults are monitored in the thread to be monitored, and if page faults are present in the thread to be monitored, the page fault type and page fault processing time are determined to form page fault management data.

[0049] S130. Perform latency diagnosis on each of the monitored threads based on the page fault management data, and determine the latency diagnosis result.

[0050] Multiple threads need to run during vehicle operation. Each thread relies on pre-cached files, which may include, but are not limited to, dynamic database files. These dependent files are stored on disk and cached in physical memory pages. Once the memory pages are loaded, the threads can start and run. If a thread accesses a dependent memory page at startup and a page fault occurs, the thread cannot continue running and must handle the missing memory page before continuing. A page fault occurs when a thread accesses a memory page that is not associated with any physical page. The causes of a page fault can be: the initial access to a virtual memory address is not associated with any physical page, thus triggering the allocation and filling of physical pages; or the physical page associated with the accessed address has been reclaimed due to memory constraints, indicating a page fault, requiring the allocation of pages and reloading of content. Accordingly, the handling of page faults includes, but is not limited to: reading the correct content from disk and writing it into the physical page; or allocating physical pages and filling them with existing content in memory.

[0051] The above-described process for handling page faults is time-consuming, necessitating monitoring of these faults. A thread configuration file is pre-maintained within the vehicle system, containing the threads required for autonomous driving. This configuration file is invoked during system startup to retrieve the threads to be monitored. During system operation, page faults are monitored for each of these threads.

[0052] Optionally, thread start monitoring functions and thread exit monitoring functions can be pre-registered. The thread start monitoring function monitors started threads, and the thread exit monitoring function exits running threads. When the thread to be monitored is detected to start, monitoring of the thread to be monitored begins; conversely, when the thread to be monitored is detected to exit, monitoring of the thread to be monitored stops.

[0053] In this embodiment, the monitoring of memory access page faults of threads is implemented through a kernel module. The kernel module has a pre-set monitoring function that can monitor the running thread in real time.

[0054] The kernel module has a pre-set page fault handling function. When a page fault is detected, the page fault can be handled by the page fault handling function, and the monitoring thread can continue to run after the page fault is handled.

[0055] Before the vehicle system leaves the factory or before it starts up, the page fault handling function of the kernel module can be preprocessed. This allows the processed kernel module to monitor the page fault handling process time, facilitating subsequent analysis based on the page fault handling time. Optionally, the preprocessing process may involve replacing the page fault handling function with a calling function and setting the function address of the page fault handling function in a preset variable. For example, the page fault handling function `handle_mm_fault` can be called by a custom function in the kernel module, such as `new_handle_mm_fault`. The `handle_mm_fault` function is replaced with `new_handle_mm_fault`, and the `handle_mm_fault` function is stored. The storage address of the page fault handling function is saved in a preset variable, such as `orig_handle_mm_fault`. In the above embodiment, replacing the page fault handling function with a calling function can be implemented through a replacement function in the kernel module, such as `text_poke_bp`.

[0056] Accordingly, upon detecting a page fault, a page fault handling function is invoked. Specifically, this can be achieved by reading the function address of the page fault handling function from a preset variable and then invoking the function based on that address. The page fault is handled through the page fault handling function, and the page fault handling time is the time consumed by calling the page fault handling function. By recording the time information of the page fault handling function call process, the page fault handling time can be determined.

[0057] When a simulated page fault occurs in the monitored thread, the page fault type and page fault processing time are determined to form page fault management data. This includes: when a simulated page fault occurs in the monitored thread, calling a page fault handling function and performing page fault processing based on the page fault handling function; recording the start and end timestamps of the page fault handling function and determining the page fault processing time based on the start and end timestamps; and determining the page fault type based on the input parameters and processing results of the page fault handling function.

[0058] Specifically, the `new_handle_mm_fault` function in the kernel module reads the memory address of the `handle_mm_fault` function from the `orig_handle_mm_fault` variable, calls the `handle_mm_fault` function from the read memory address, and performs page fault handling based on this `handle_mm_fault` function. During the call to the page fault handling function, the start and end timestamps of the call are recorded. The time difference between the start and end timestamps determines the page fault handling time for the current instance.

[0059] Different causes lead to different types of page faults. For example, the types of page faults include: a major page fault (Type 1) and a minor page fault (Type 2). A major page fault occurs when the memory to be accessed is neither in the virtual address space nor in physical memory, requiring loading from a slow device (i.e., disk). A minor page fault occurs when the memory to be accessed is not in the virtual address space but is in physical memory, requiring the MMU to establish a mapping between physical memory and the virtual address space.

[0060] The different page fault types mentioned above are resolved through different processing methods. Accordingly, the page fault type can be determined by the input parameters and processing results of the page fault handling function. There is a correspondence between the page fault type and the input parameters and processing results of the page fault handling function; this correspondence can be used to determine the corresponding page fault type.

[0061] The determined page fault types and page fault handling times, along with the thread identifiers of the threads to be monitored, are associated and stored to form page fault management data. This page fault management data is in the form of a structure tree, including the thread identifiers of each thread to be monitored and the number of page faults, page fault types, and page fault handling times for each monitored thread within each monitoring period. Specifically, the page fault types and page fault handling times of the monitored threads can be read from the kernel module based on the monitoring period. The number of page faults within that monitoring period is counted, and the corresponding page fault counts, page fault types, and page fault handling times are stored in the storage location of the thread identifier, thus updating the page fault management data. The monitoring period can be determined based on the granularity of the monitoring, for example, it could be 1 second, and there is no limitation thereto.

[0062] Page fault management data can be in the form of a radix-tree, a list, or a dataset; there are no restrictions on the data structure. Creating page fault management data facilitates the management and analysis of page fault handling information for each thread within any monitoring period, enabling the diagnosis of latency causes during thread execution and determining whether memory access page faults are the primary cause of latency.

[0063] Optionally, latency diagnosis is performed on each of the monitored threads based on the page fault management data to determine the latency diagnosis result, including: determining the processing time of the monitored thread for any processing path, and determining whether the monitored thread meets the latency diagnosis condition based on the processing time; if so, it is determined whether the total page fault processing time corresponding to each page fault type exceeds the corresponding latency threshold during the operation of the monitored thread; if the total page fault processing time corresponding to any page fault type exceeds the corresponding latency threshold, then the simulated memory page fault phenomenon is determined to be the main cause of latency.

[0064] In this embodiment, for any thread, during its execution, the processing time for each processing path is determined. Based on this processing time, it is determined whether there is excessive latency. Specifically, the processing time is compared with the standard processing time (or historical average processing time) to determine the difference. If the difference is greater than a preset threshold, it indicates that the thread has significant latency, meeting the latency diagnosis criteria, and latency diagnosis is required. If the difference is less than the preset threshold, it indicates that the thread has minimal latency, not meeting the latency diagnosis criteria, and latency diagnosis is not required. The processing time for each processing path can be determined based on the timestamps in the thread log information. For example, a business log is generated before and after the thread processes the processing path. Based on these business logs, the start and end times of processing can be read, and the processing time can be determined accordingly.

[0065] For a monitored thread that meets the latency diagnosis criteria, read the corresponding page fault processing data from the page fault management data. This includes data such as the page fault type and page fault processing time for each page fault. Specifically, the page fault processing data can be data within the time period between the aforementioned processing start time information and processing end time information.

[0066] The total processing time for each page fault type is calculated by summing the page fault processing times for each page fault type. It is then determined whether the total processing time for each page fault type exceeds the corresponding latency threshold. If the total processing time for any page fault type exceeds the corresponding latency threshold, the main cause of the latency in the monitored thread is determined to be a memory access page fault. If the total processing time for each page fault type does not exceed the corresponding latency threshold, then the memory access page fault is not the main cause of the latency in the monitored thread.

[0067] The latency threshold corresponding to each page fault type can be determined by the processing time and a preset ratio, such as 10%. The latency threshold can then be determined by multiplying the processing time by the preset ratio. Different page fault types can have different preset ratios.

[0068] Parallel diagnostics can be performed on multiple monitored threads to determine the latency diagnosis results for each thread. These latency diagnosis results can determine whether page faults are the primary cause of latency, allowing for further optimization to reduce latency.

[0069] The technical solution provided in this embodiment monitors the memory access page fault phenomenon of the thread during thread operation and records the page fault processing time and page fault type. This facilitates the diagnosis of the cause of latency during thread processing, and helps to optimize the thread operation process based on the latency diagnosis results. This further optimizes the operation of the vehicle system and ensures the normal operation of the vehicle during operation.

[0070] Building upon the above embodiments, to specifically optimize thread execution, particularly for page fault handling, after determining the page fault type and page fault processing time, page fault information for each monitored thread is recorded according to recording rules, forming a time-consuming log. Recording page fault information in the time-consuming log facilitates analysis and optimization of the page fault phenomenon when it is determined that page faults are the primary cause of latency. The page fault information includes, but is not limited to, the thread identifier of the monitored thread, page fault processing time, the file path that triggered the page fault, and the user call stack.

[0071] The recording rules include recording methods corresponding to different page fault processing times and different page fault types. Each recording method includes different sampling ratios and recording content. Specifically, in each instance of a memory access page fault, the recording rules are matched based on the page fault processing time and page fault type to determine whether to record the current page fault information. If so, a log entry is generated based on the page fault information and added to the processing time log.

[0072] Optionally, page fault information of each monitored thread is recorded according to recording rules to form a time consumption log, including: if the page fault processing time is greater than a first preset threshold, the current page fault information is recorded; if the page fault processing time is less than the first preset threshold, the ratio of the number of page faults in the current monitoring period to the number of page faults in the previous monitoring period is determined, and a sampling recording ratio is determined according to the ratio, and the current page fault information is recorded according to the sampling recording ratio.

[0073] If the page fault processing time exceeds the first preset threshold, it indicates that the current page fault processing is time-consuming. The page fault information corresponding to this current page fault processing needs to be recorded, and a log message is generated based on the page fault information and stored as a time consumption log. The first preset threshold can be a pre-set comparison threshold, for example, 10 microseconds.

[0074] If the page fault processing time is less than the first preset threshold, it indicates that the current page fault processing does not take a significant amount of time. To avoid excessive logging of processing time, page fault information can be sampled and recorded according to a preset sampling ratio. The sampling ratio can vary depending on different situations, allowing for targeted recording with varying degrees of density, reducing the amount of recorded information while ensuring that no critical page fault information is missed.

[0075] Specifically, the process involves determining the ratio of page misses in the current monitoring period to those in the previous monitoring period. Based on the data segment and missing type of this ratio, a corresponding sampling record ratio is determined, and page miss information is recorded accordingly. For the current page miss processing, based on the corresponding page miss type, the number of page misses of that type in the current monitoring period and the number of page misses of that type in the previous monitoring period are determined, and the ratio of page misses in the current monitoring period to those in the previous monitoring period is also determined.

[0076] Determine whether the ratio of page faults in the current monitoring period to page faults in the previous monitoring period exceeds a first ratio value. If not, record the first page fault type based on a first sampling record ratio, and record the second page fault type based on a second sampling record ratio. For example, the first sampling record ratio could be 5%, and the second sampling record ratio could be 1%. The page fault information recorded for the first page fault type includes page fault duration information, user-mode call stack, and the file path that triggered the page fault. The page fault information recorded for the second page fault type includes page fault duration information and user-mode call stack.

[0077] If the ratio of page misses in the current monitoring period to page misses in the previous monitoring period exceeds a first ratio, then it is further determined whether the ratio exceeds a second ratio, where the second ratio is greater than the first ratio. If yes, the first page miss type is recorded based on a third sampling record ratio, and the second page miss type is recorded based on a fourth sampling record ratio, where the third sampling record ratio can be 1% and the fourth sampling record ratio can be 0.5%. If no, the first page miss type is recorded based on a fifth sampling record ratio, and the second page miss type is recorded based on a sixth sampling record ratio, where the fifth sampling record ratio can be 10% and the sixth sampling record ratio can be 5%.

[0078] Based on the sampling record ratio determined by the above method, it is determined whether to store the page fault information of the current page fault processing, and a time consumption record log is formed.

[0079] Accordingly, if the total time spent on page fault processing for any page fault type exceeds the corresponding latency threshold, the method further includes: sampling the logs corresponding to the page fault type from the time-consuming logs, visualizing the sampled logs, and / or determining optimizable points based on the sampled logs.

[0080] Specifically, if the total processing time for the second page fault type exceeds the corresponding latency threshold, determine whether the processing time for a single page fault of the second page fault type exceeds the first single latency threshold (e.g., 1 millisecond). If so, it indicates a lag in the vehicle system's memory allocation management. Query the memory management log and visualize it to facilitate problem localization for operators. If not, query the processing time log and visualize the second page fault type log information to help operators identify optimization points based on the log information. Specifically, extract the log information corresponding to the second page fault type from the processing time log and determine optimization points based on the user-mode call stack in the log information.

[0081] If the total processing time for the first page fault type exceeds the corresponding latency threshold, determine whether the processing time for a single page fault of the first page fault type exceeds the second single latency threshold (e.g., 10 milliseconds). If yes, identify potential optimization points from the file path and user-mode call stack corresponding to the first page fault type in the processing log. If no, identify potential optimization points from the user-mode call stack corresponding to the first page fault type in the processing log.

[0082] Among these optimization points, there are ways to reduce latency, including but not limited to preloading files that experience page faults and latching files that experience page faults to prevent them from being reclaimed.

[0083] The technical solution of this embodiment records page fault information of page fault processing that causes delay according to recording rules to form a time consumption log, which facilitates targeted analysis and optimization based on the time consumption log, and further improves the operating efficiency of the vehicle system.

[0084] Figure 2 This is a schematic diagram of the structure of a time delay diagnostic device for an in-vehicle system provided in an embodiment of the present invention. Figure 2 As shown, the device includes:

[0085] The thread to be monitored module 210 is used to determine the thread to be monitored in response to the startup of the vehicle system;

[0086] The memory access page fault monitoring module 220 is used to monitor the memory access page fault during the operation of the thread to be monitored, and to determine the page fault type and page fault processing time when the thread to be monitored has a memory access page fault phenomenon, and to form page fault management data.

[0087] The latency diagnosis module 230 is used to perform latency diagnosis on each of the monitored threads based on the page fault management data and determine the latency diagnosis result.

[0088] Optionally, the memory access page fault monitoring module 220 is used for:

[0089] If a page fault occurs in the thread to be monitored, the page fault handling function is called, and page fault handling is performed based on the page fault handling function.

[0090] Record the start and end timestamps of the page fault handling function, and determine the page fault handling time based on the start and end timestamps;

[0091] Based on the input parameters and processing results of the page fault handling function, the page fault type is determined.

[0092] Optionally, the device may also include:

[0093] The function preprocessing module is used to replace the page fault handling function with a calling function, and to set the function address of the page fault handling function in a preset variable;

[0094] Accordingly, the memory access page fault monitoring module 220 is used for:

[0095] The function call function reads the address of the page fault handling function from the preset variables and calls the page fault handling function based on the function address.

[0096] Optionally, the page fault management data is in the form of a structure tree, including the thread identifier of each thread to be monitored and the number of page faults, page fault types, and page fault processing time of each thread in each monitoring period.

[0097] Optionally, the delay diagnostic module 230 is used for:

[0098] Determine the processing time of the thread to be monitored for any processing path, and determine whether the thread to be diagnosed meets the latency diagnosis conditions based on the processing time;

[0099] If so, then determine whether the total time spent on page fault processing for each page fault type exceeds the corresponding latency threshold during the execution of the thread to be diagnosed.

[0100] If the total time spent on page fault processing for any page fault type exceeds the corresponding latency threshold, then the simulated memory page fault phenomenon is determined to be the main cause of latency.

[0101] Optionally, the device preferably includes:

[0102] The logging module is used to record the page fault information of each monitored thread according to the recording rules after determining the page fault type and page fault processing time, forming a time-consuming log.

[0103] The log processing module is used to sample the log corresponding to the page fault type from the time-consuming log when the page fault processing time for any page fault type exceeds the corresponding latency threshold, and to visualize the sampled log, and / or to determine the optimizable points based on the sampled log.

[0104] Optionally, the logging module is used for:

[0105] If the page fault processing time is greater than a first preset threshold, the current page fault information is recorded; if the page fault processing time is less than the first preset threshold, the ratio of the number of page faults in the current monitoring period to the number of page faults in the previous monitoring period is determined, and a sampling recording ratio is determined according to the ratio, and the current page fault information is recorded according to the sampling recording ratio.

[0106] The vehicle system delay diagnosis device provided in this embodiment of the invention can execute the vehicle system delay diagnosis method provided in any embodiment of the invention, and has the corresponding functional modules and beneficial effects of the method.

[0107] Figure 3 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention. The electronic device 10 is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device may also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices (such as helmets, glasses, watches, etc.), and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the invention described and / or claimed herein.

[0108] like Figure 3As shown, the electronic device 10 includes at least one processor 11 and a memory, such as a read-only memory (ROM) 12 or a random access memory (RAM) 13, communicatively connected to the at least one processor 11. The memory stores computer programs executable by the at least one processor. The processor 11 can perform various appropriate actions and processes based on the computer program stored in the ROM 12 or loaded from storage unit 18 into the RAM 13. The RAM 13 may also store various programs and data required for the operation of the electronic device 10. The processor 11, ROM 12, and RAM 13 are interconnected via a bus 14. An input / output (I / O) interface 15 is also connected to the bus 14.

[0109] Multiple components in electronic device 10 are connected to I / O interface 15, including: input unit 16, such as keyboard, mouse, etc.; output unit 17, such as various types of displays, speakers, etc.; storage unit 18, such as disk, optical disk, etc.; and communication unit 19, such as network card, modem, wireless transceiver, etc. Communication unit 19 allows electronic device 10 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0110] Processor 11 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of processor 11 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various processors running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. Processor 11 performs the various methods and processes described above, such as latency diagnostic methods for in-vehicle systems.

[0111] In some embodiments, the latency diagnosis method for the vehicle system can be implemented as a computer program tangibly contained in a computer-readable storage medium, such as storage unit 18. In some embodiments, part or all of the computer program can be loaded and / or installed on the electronic device 10 via ROM 12 and / or communication unit 19. When the computer program is loaded into RAM 13 and executed by processor 11, one or more steps of the latency diagnosis method for the vehicle system described above can be performed. Alternatively, in other embodiments, processor 11 can be configured to perform the latency diagnosis method for the vehicle system by any other suitable means (e.g., by means of firmware).

[0112] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), payload-programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0113] The computer program for implementing the delay diagnosis method of the vehicle system of the present invention can be written in any combination of one or more programming languages. These computer programs can be provided to the processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device, such that when executed by the processor, the computer program causes the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The computer program can be executed entirely on the machine, partially on the machine, as a standalone software package partially on the machine and partially on a remote machine, or entirely on a remote machine or server.

[0114] This invention also provides a computer-readable storage medium storing computer instructions for causing a processor to execute a latency diagnosis method for an in-vehicle system, the method comprising:

[0115] In response to the startup of the vehicle system, determine the thread to be monitored;

[0116] During the operation of the thread to be monitored, page faults are monitored for the thread to be monitored, and if page faults occur in the thread to be monitored, the page fault type and page fault processing time are determined to form page fault management data.

[0117] Based on the page fault management data, latency diagnosis is performed on each of the monitored threads to determine the latency diagnosis result.

[0118] In the context of this invention, a computer-readable storage medium can be a tangible medium that may contain or store a computer program for use by or in conjunction with an instruction execution system, apparatus, or device. A computer-readable storage medium may include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination thereof. Alternatively, a computer-readable storage medium may be a machine-readable signal medium. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0119] To provide interaction with a user, the systems and techniques described herein can be implemented on an electronic device having: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user; and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the electronic device. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0120] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as data servers), or computing systems that include middleware components (e.g., application servers), or computing systems that include frontend components (e.g., user computers with graphical user interfaces or web browsers through which users can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., communication networks). Examples of communication networks include local area networks (LANs), wide area networks (WANs), blockchain networks, and the Internet.

[0121] A computing system can include clients and servers. Clients and servers are generally located far apart and typically interact through a communication network. The client-server relationship is created by computer programs running on the respective computers and having a client-server relationship with each other. The server can be a cloud server, also known as a cloud computing server or cloud host, which is a hosting product within the cloud computing service system to address the shortcomings of traditional physical hosts and VPS services, such as high management difficulty and weak business scalability.

[0122] It should be understood that the various forms of processes shown above can be used, with steps reordered, added, or deleted. For example, the steps described in this invention can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution of this invention can be achieved, and this is not limited herein.

[0123] The specific embodiments described above do not constitute a limitation on the scope of protection of this invention. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this invention should be included within the scope of protection of this invention.

Claims

1. A time delay diagnosis method for an in-vehicle system, characterized in that, include: In response to the startup of the vehicle system, the thread to be monitored is determined, which is the thread that needs to run during the automatic driving process of the vehicle; During the operation of the thread under monitoring, memory access page faults are monitored. If a memory access page fault occurs in the thread under monitoring, the page fault type and page fault processing time are determined to form page fault management data. The page fault processing time is the time taken to call the page fault processing function to perform page fault processing, and the page fault type is determined based on the input parameters and processing result of the page fault processing function. Based on the page fault management data, latency diagnosis is performed on each of the monitored threads to determine the latency diagnosis result.

2. The method according to claim 1, characterized in that, When a page fault occurs in the monitored thread, the page fault type and page fault processing time are determined to form page fault management data, including: If a page fault occurs in the thread to be monitored, the page fault handling function is invoked, and page fault handling is performed based on the page fault handling function. Record the start and end timestamps of the page fault handling function, and determine the page fault handling time based on the start and end timestamps; Based on the input parameters and processing results of the page fault handling function, the page fault type is determined.

3. The method according to claim 2, characterized in that, The method further includes: Replace the page fault handling function with a calling function, and set the function address of the page fault handling function in a preset variable; Accordingly, the invocation of the page fault handling function includes: The function call function reads the address of the page fault handling function from the preset variables and calls the page fault handling function based on the function address.

4. The method according to claim 1, characterized in that, The page fault management data is in the form of a structure tree, including the thread identifier of each thread to be monitored and the number of page faults, page fault types, and page fault processing time of each monitored thread in each monitoring period.

5. The method according to claim 1, characterized in that, The step of performing latency diagnosis on each of the monitored threads based on the page fault management data and determining the latency diagnosis result includes: Determine the processing time of the thread to be monitored for any processing path, and determine whether the thread to be diagnosed meets the latency diagnosis conditions based on the processing time; If so, then determine whether the total time spent on page fault processing for each page fault type exceeds the corresponding latency threshold during the execution of the thread to be diagnosed. If the total time spent handling page faults for any page fault type exceeds the corresponding latency threshold, then memory access page faults are determined to be the main cause of latency.

6. The method according to claim 1, characterized in that, After determining the page fault type and page fault processing time, the method further includes: Page fault information for each thread to be monitored is recorded according to the recording rules to form a time consumption log; Accordingly, if the page fault processing time for any page fault type exceeds the corresponding latency threshold, the method further includes: From the time-consuming log, sample the logs corresponding to the page fault type, visualize the sampled logs, and / or determine optimizable points based on the sampled logs.

7. The method according to claim 6, characterized in that, The process of recording page fault information for each monitored thread according to recording rules to form a time-consuming log includes: If the page fault processing time exceeds the first preset threshold, the current page fault information is recorded. If the page fault processing time is less than the first preset threshold, the ratio of the number of page faults in the current monitoring period to the number of page faults in the previous monitoring period is determined, and the sampling record ratio is determined according to the ratio. The current page fault information is then recorded according to the sampling record ratio.

8. A time delay diagnostic device for an in-vehicle system, characterized in that, include: The monitoring thread determination module is used to determine the monitoring thread in response to the startup of the vehicle system. The monitoring thread is the thread that needs to run during the automatic driving process of the vehicle. The memory access page fault monitoring module is used to monitor the memory access page faults of the thread under monitoring during its operation, and to determine the page fault type and page fault processing time when a page fault occurs in the thread under monitoring, thereby forming page fault management data; wherein, the page fault processing time is the time taken to call the page fault processing function to perform page fault processing, and the page fault type is determined based on the input parameters and processing result of the page fault processing function; The latency diagnosis module is used to perform latency diagnosis on each of the monitored threads based on the page fault management data and determine the latency diagnosis result.

9. An electronic device, characterized in that, The electronic device includes: At least one processor; and A memory communicatively connected to the at least one processor; wherein, The memory stores a computer program that can be executed by the at least one processor, the computer program being executed by the at least one processor to enable the at least one processor to perform the time delay diagnosis method of the vehicle system according to any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions that, when executed by a processor, implement the delay diagnosis method of the vehicle system according to any one of claims 1-7.

Images