Method, device and storage medium for determining vehicle malfunction

Abstract

The application provides a vehicle fault determination method and device and a storage medium. It relates to the technical field of data processing. The method comprises the following steps: acquiring first fault information of a vehicle during driving, wherein the first fault information comprises description information and an occurrence period; performing space-time extraction on the first fault information according to the description information and the occurrence period to obtain a plurality of second fault information, and determining corresponding fault event information according to the plurality of second fault information; performing hierarchical fault identification on the fault event information according to a preset rule base to determine the corresponding causal information chain of each fault event information; determining a plurality of target fault root causes according to each fault event information and the corresponding causal information chain, and generating a fault report of the vehicle according to the plurality of target fault root causes. The accuracy of determining vehicle faults is improved.

Description

Technical Field

[0001] This application relates to the field of data processing technology, and in particular to a method, device and storage medium for determining vehicle faults. Background Technology

[0002] In intelligent driving scenarios, vehicles continuously generate massive amounts of fault log data during road testing and operation, and retain this data through data feedback and other methods for subsequent troubleshooting and system optimization.

[0003] In related technologies, troubleshooting is usually done manually, where technicians manually complete the entire troubleshooting process, including log downloading, fault analysis, and problem localization, based on actual needs.

[0004] However, in the above process, as the complexity of autonomous driving systems continues to increase, the amount of fault log data grows exponentially. Relying solely on human experience to judge faults can easily lead to misjudgment of root causes and deviations in fault location, resulting in low accuracy in determining vehicle faults. Summary of the Invention

[0005] This application provides a method, device, and storage medium for determining vehicle faults, in order to solve the problem of low accuracy in determining vehicle faults.

[0006] In a first aspect, this application provides a method for determining vehicle malfunctions, comprising:

[0007] Obtain the first fault information of the vehicle during driving. The first fault information includes description information and the time of occurrence.

[0008] Based on the description information and the time period of occurrence, the first fault information is spatiotemporally extracted to obtain multiple second fault information, and the corresponding fault event information is determined based on the multiple second fault information;

[0009] Based on a pre-defined rule base, hierarchical fault identification is performed on fault event information to determine the causal information chain corresponding to each fault event.

[0010] Based on the information of each fault event and the corresponding causal information chain, multiple target fault root causes are identified, and a vehicle fault report is generated based on these multiple target fault root causes.

[0011] In one possible implementation, based on the description information and the time period of occurrence, spatiotemporal extraction is performed on the first fault information to obtain multiple second fault information items, including:

[0012] Based on the description information, spatial extraction is performed on the first fault information to obtain the third fault information;

[0013] Based on the time period of occurrence, the third fault information is extracted in time sequence to obtain multiple second fault information.

[0014] In one possible implementation, the corresponding fault event information is determined based on multiple second fault information pieces, including:

[0015] Determine whether each of the second fault messages contains a hardware fault;

[0016] When a hardware fault is detected in the second fault information, the second fault information is processed according to timing to obtain fault event information.

[0017] In one possible implementation, the second fault information is subjected to timing processing to obtain fault event information, including:

[0018] Based on a preset time window, the second fault information is filtered to obtain multiple adjacent fault events;

[0019] Multiple adjacent fault events are sorted and reorganized to obtain fault event information.

[0020] In one possible implementation, hierarchical fault identification is performed on fault event information based on a preset rule base to determine the causal information chain corresponding to each fault event, including:

[0021] For any fault event information, the rule base is traversed layer by layer to see if there is a corresponding fault event information. When it is determined that there is no corresponding fault event information, the current fault level is determined as the root cause level.

[0022] Generate a causal information chain based on the root cause hierarchy.

[0023] In one possible implementation, multiple target root causes of failures are determined based on information about each failure event and the corresponding causal information chain, including:

[0024] Based on the pre-trained language model, information on each fault event, and the corresponding causal information chain, multiple candidate root causes of the fault are identified.

[0025] Multiple target root causes are identified from a pool of candidate root causes.

[0026] In one possible implementation, multiple target root causes are identified from a plurality of candidate root causes, including:

[0027] Determine the event weight, hierarchy weight, scope weight, and repair weight for each candidate root cause of failure;

[0028] Based on the event weight, hierarchy weight, scope weight, and repair weight, calculate the fault score for each candidate root cause, and obtain multiple target root causes based on the fault scores.

[0029] In one possible implementation, a vehicle fault report is generated based on multiple target root causes, including:

[0030] Search the preset knowledge base to obtain historical failure cases that match the root cause of the target failure.

[0031] A fault report is generated based on a pre-trained language model, historical fault cases, and the target fault root cause.

[0032] Secondly, this application provides a vehicle fault determination device, wherein:

[0033] The acquisition module is used to acquire the first fault information of the vehicle during driving. The first fault information includes description information and the time period of occurrence.

[0034] The determination module is used to perform spatiotemporal extraction on the first fault information based on the description information and the time period of occurrence, to obtain multiple second fault information, and to determine the corresponding fault event information based on the multiple second fault information;

[0035] The identification module is used to perform hierarchical fault identification on fault event information according to a preset rule base, and to determine the causal information chain corresponding to each fault event information.

[0036] The processing module is used to determine multiple target fault root causes based on each fault event information and the corresponding causal information chain, and to generate a vehicle fault report based on the multiple target fault root causes.

[0037] Thirdly, embodiments of this application provide a vehicle fault determination device, comprising: at least one processor and a memory; the memory storing computer-executable instructions; at least one processor executing the computer-executable instructions stored in the memory, causing at least one processor to perform the vehicle fault determination method as described in the first aspect above and any one of the first aspects.

[0038] Fourthly, embodiments of this application provide a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, implement the vehicle fault determination method as described in the first aspect and any one of the first aspects.

[0039] The vehicle fault determination method, device, and storage medium provided in this application acquire first fault information containing descriptive information and the time period of occurrence. Multiple second fault information items are obtained by spatiotemporal extraction of the first fault information based on the descriptive information and the time period of occurrence. Corresponding fault event information is determined based on these multiple second fault information items. Hierarchical fault identification is performed on the fault event information according to a preset rule base to determine the causal information chain corresponding to each fault event information item. Multiple target fault root causes are determined based on each fault event information item and its corresponding causal information chain. A fault report is generated based on these multiple target fault root causes. In this method, electronic devices can determine target fault root causes by performing spatiotemporal extraction and hierarchical fault identification on fault information, combined with causal reasoning. This enables rapid location of the root cause in massive fault logs, effectively avoiding the problems of root cause misjudgment and location bias that exist in manual analysis, improving analysis efficiency, and accurately determining the root cause of vehicle faults. Furthermore, this method is applicable to the fault diagnosis needs of different autonomous driving systems, reducing reliance on experts and improving fault handling efficiency while increasing fault location accuracy. Attached Figure Description

[0040] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0041] Figure 1 This is a schematic diagram illustrating an application scenario provided in the embodiments of this application;

[0042] Figure 2 A flowchart illustrating a method for determining vehicle faults provided in an embodiment of this application;

[0043] Figure 3 A schematic diagram illustrating the process of determining fault event information provided in an embodiment of this application;

[0044] Figure 4 A schematic diagram illustrating the process of determining the causal information chain provided in the embodiments of this application;

[0045] Figure 5 A schematic diagram illustrating the hierarchical fault identification process provided in an embodiment of this application;

[0046] Figure 6 A flowchart illustrating a method for determining multiple target fault root causes provided in an embodiment of this application;

[0047] Figure 7 A flowchart illustrating the method for determining multiple target fault root causes provided in the embodiments of this application;

[0048] Figure 8 A schematic diagram illustrating the fault report processing procedure provided in this application embodiment;

[0049] Figure 9 A flowchart illustrating another method for determining vehicle faults provided in this application embodiment;

[0050] Figure 10 A schematic diagram of a vehicle fault determination device provided in an embodiment of this application;

[0051] Figure 11 This is a schematic diagram of the structure of the vehicle fault determination device provided in the embodiments of this application.

[0052] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0053] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0054] It should be noted that in the embodiments of this application, certain software, components, models and other existing solutions in the industry may be mentioned. These should be regarded as exemplary and are only intended to illustrate the feasibility of implementing the technical solution of this application. However, it does not mean that the applicant has used or necessarily used the solution.

[0055] Autonomous driving fault diagnosis technology is widely used in the research, development, testing, and road operation phases of advanced autonomous vehicles for system health management and problem identification. During vehicle operation, it is necessary to record and transmit massive amounts of operational logs generated by multiple modules such as perception, localization, planning, and control in real time. When anomalies occur, log analysis is used to locate the root cause of the fault, ensuring that system problems can be repaired in a timely manner and that vehicle safety and reliability are continuously improved.

[0056] In related technologies, fault diagnosis for autonomous driving usually adopts a manual inspection method. That is, technicians manually filter and download the corresponding log files according to the time period of the fault, and check the information recorded in the logs such as module operation status, communication anomalies, and resource usage item by item. They combine their personal experience to judge the cause of the fault and locate the problematic module.

[0057] However, in the above process, as the complexity of autonomous driving systems continues to increase, a single fault often involves the cascading effects of multiple modules such as perception, planning, and control. The amount of fault log data grows exponentially. Relying solely on human experience to judge faults can easily lead to misjudgment of root causes and deviations in fault location, resulting in low accuracy in determining vehicle faults.

[0058] Furthermore, the entire fault handling process involves log downloading, item-by-item troubleshooting, and problem localization, which requires a lot of manpower and time, resulting in low efficiency in handling vehicle faults.

[0059] Therefore, this application provides a method for determining vehicle faults. By acquiring first fault information containing descriptive information and the time period of occurrence, multiple second fault information is obtained by spatiotemporal extraction of the first fault information and the corresponding fault event information is determined. The fault event information is then subjected to hierarchical fault identification according to a preset rule base to determine the causal information chain corresponding to each fault event information. Multiple target fault root causes are determined based on each fault event information and the corresponding causal information chain, and a fault report is generated. This method accurately captures contextual information before and after the fault trigger point from massive logs through spatiotemporal extraction. It constructs a bottom-up fault propagation hierarchy model through hierarchical fault identification and performs hierarchical penetration reasoning to eliminate apparent faults and trace the root cause hierarchy. It can accurately distinguish between root cause and apparent faults in multi-module cascaded fault scenarios, effectively avoiding root cause misjudgment and location deviation caused by differences in human experience. Furthermore, by having the rule base output the root cause of deterministic faults such as hardware resource anomalies in the hierarchical identification pre-stage, and having the large model perform semantic understanding and supplementary verification based on causal reasoning for complex faults, a two-layer diagnostic architecture of rule base and large model collaboration is formed, which greatly shortens the fault diagnosis time and improves fault handling efficiency while improving fault location accuracy.

[0060] To facilitate understanding, the following will be combined with... Figure 1 The application scenarios applicable to the embodiments of this application will be described.

[0061] Figure 1 This is a schematic diagram illustrating an application scenario provided in an embodiment of this application. Please refer to [link / reference]. Figure 1 This includes vehicles and vehicle fault determination equipment, which can be deployed in vehicles.

[0062] When a vehicle needs to locate a fault, the vehicle collects relevant fault information through a fault-determination device, processes the fault information, determines the root cause of the fault and the corresponding fault report, thereby achieving more efficient and accurate autonomous driving fault diagnosis and improving the efficiency of fault handling and the accuracy of fault location.

[0063] The technical solution of this application and how it solves the above-mentioned technical problems will be described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will be described below with reference to the accompanying drawings.

[0064] Figure 2 This is a flowchart illustrating a method for determining vehicle faults provided in an embodiment of this application. Please refer to [link / reference]. Figure 2 As shown, the method may include the following steps:

[0065] S201. Obtain the first fault information of the vehicle during driving.

[0066] The execution subject of this application embodiment can be an electronic device or a vehicle fault determination device installed in an electronic device. The vehicle fault determination device can be implemented by software or by a combination of software and hardware.

[0067] The first fault information includes a description and the time period in which it occurred.

[0068] The first fault information can refer to the original fault data generated during vehicle operation that is related to system operating status, module abnormality, communication timeout, resource overload, etc., including but not limited to log file packages, problem ticket descriptions, real-time streaming data, etc.

[0069] Description information can refer to text information that describes the fault phenomenon in natural language or records it in a structured manner. For example, the problem title and detailed description in the problem form, the error code and stack information recorded in the log file, and the alarm content output when the system is abnormal.

[0070] The occurrence period can refer to the time range in which the fault occurs, specifically including the fault start time stamp and end time stamp, or the time interval before and after the fault trigger point.

[0071] In some embodiments, obtaining first fault information of a vehicle during operation can be achieved through at least one of the following methods:

[0072] Method 1 involves uploading and importing log packages. The electronic device provides a log upload interface to receive log file packages uploaded by external devices (such as drive test data acquisition terminals, cloud storage servers, etc.). Log package formats include, but are not limited to, .tar.gz and .zip. After receiving the log package, the electronic device performs an MD5 checksum to confirm that the log file has not been tampered with or corrupted during transmission, ensuring that the log data used for subsequent analysis is consistent with the original data.

[0073] Meanwhile, the electronic device employs a streaming decompression strategy to decompress the log packets, meaning that data is streamed into the subsequent processing queue while decompressing, avoiding loading the entire compressed package into memory and thus preventing memory overflow. After decompression, the electronic device performs format and version alignment checks on the log files to ensure that they conform to the parsing specifications of subsequent processing modules.

[0074] Method two involves integration with the issue ticket system. Electronic devices provide an Application Programming Interface (API) endpoint. When an issue ticket is created or updated, the issue ticket system pushes fault information to the electronic device through this endpoint. The pushed information includes: the issue ticket's associated identifier, a link to the log attachment on the cloud storage service, a description of the problem, and the reporter's information (for subsequent notification to relevant personnel via instant messaging applications).

[0075] Method three is real-time streaming access. For scenarios with integrated vehicle-cloud real-time monitoring capabilities, electronic devices establish a long-term connection with onboard data acquisition equipment via a streaming communication protocol to receive real-time operational status data and fault information reported by the vehicle during operation. This streaming communication protocol is based on a bidirectional streaming transmission mechanism and uses an efficient serialization method, offering advantages such as low latency and bidirectional streaming communication, making it suitable for scenarios requiring real-time monitoring and immediate fault detection.

[0076] S202. Based on the description information and the time period of occurrence, perform spatiotemporal extraction on the first fault information to obtain multiple second fault information, and determine the corresponding fault event information based on the multiple second fault information.

[0077] The second fault information refers to a set of log fragments that are spatiotemporally related to the fault trigger point, selected from the original log data after spatiotemporal extraction. Each piece of second fault information includes the call context of the module where the fault trigger point is located in the spatial dimension and the adjacent logs in the temporal dimension, providing a data foundation for subsequent determination of fault event information.

[0078] Fault event information refers to event units with clear fault category identifiers and occurrence timestamps, obtained by further structuring the log fragments in the second fault information. Each fault event information corresponds to a specific fault phenomenon or abnormal behavior, and multiple fault event information pieces together constitute the input event set for fault analysis.

[0079] In some embodiments, the electronic device employs a multi-stage pipelined processing architecture, using a producer-consumer model to perform parallel parsing of heterogeneous logs. Specifically, the electronic device decomposes the log processing into multiple stages, including reading, decompression, parsing, and index building. Each stage is handled by an independent thread pool and blocking queue. Data is transferred between different stages via queues, allowing I / O wait time to overlap with Central Processing Unit (CPU) computation time, thus improving overall throughput. For parallelism control, the electronic device dynamically adjusts the number of threads in each stage based on the current number of CPU cores, avoiding disk I / O contention and CPU scheduling anomalies caused by excessive threads. For memory management, the electronic device uses a circular buffer to control the memory limit for single-file processing, with a default limit of 256MB, ensuring single-task fault isolation and preventing memory overflow triggered by processing a single large file.

[0080] Understandably, fault log data is characterized by multi-source asynchronous processing, heterogeneous formats, and massive redundancy. Taking an autonomous driving system as an example, the perception module outputs detection results, the localization module outputs location information, and the planning and control module outputs decision commands. Logs from different modules are scattered across different thread buffers, with independent timestamps. Directly performing full-text search or line-by-line scanning on the raw logs would not only incur enormous computational overhead but also make it difficult to aggregate asynchronous logs from different modules occurring at the same physical moment. Therefore, spatiotemporal extraction is needed to reduce the dimensionality of massive logs, accurately capturing effective information before and after the fault trigger point.

[0081] In some embodiments, the first fault information can be spatiotemporally extracted based on the description information and the time period of occurrence to obtain multiple second fault information: the first fault information is spatially extracted based on the description information to obtain third fault information; and the third fault information is temporally extracted based on the time period of occurrence to obtain multiple second fault information.

[0082] The third fault information can refer to a set of context log fragments extracted spatially from the lines immediately before and after the fault trigger point. Understandably, the third fault information retains the relevant logs from the trigger point and its call chain, while discarding irrelevant and redundant log lines.

[0083] In some embodiments, the electronic device first scans the log file using a multi-pattern string matching algorithm based on keywords (e.g., ERROR, etc.) in the description information, and identifies the lines containing the above keywords as fault trigger points (denoted as trigger_line).

[0084] For each fault trigger point, the electronic device starts from the position of that row and traverses forward a preset number of rows (e.g., the first 10 rows) to obtain the call context information before the trigger point occurred, including the function call chain and the passed parameter values. At the same time, it traverses backward a preset number of rows (e.g., the last 5 rows) to obtain the system feedback information after the trigger point occurred, including the return value and the exception handling process. The forward and backward traversals together constitute the spatial dimension of context extraction, namely the fixed number of rows buffered as the first 10 and the last 5 rows.

[0085] In some embodiments, the electronic device parses the timestamp (denoted as curr_ts) of the row containing the fault trigger point and determines the size of the sliding time window (denoted as time_window_ms, for example, 500ms) based on the occurrence period in the description information. The electronic device calculates the time window boundaries according to the following formulas: the forward time boundary is start_ts = curr_ts - time_window_ms, and the backward time boundary is end_ts = curr_ts + time_window_ms.

[0086] The electronic device uses `start_ts` and `end_ts` as constraints to filter all log lines whose timestamps fall within the specified interval from the third fault information. Through these dual spatial and temporal constraints, asynchronous logs from multiple modules that were originally scattered across different locations in the file but occurred at the same physical moment are aggregated into a single context fragment, solving the problem of scattered and difficult-to-correlate logs in distributed systems.

[0087] By employing the above methods, electronic devices utilize spatial dimension call context extraction and temporal dimension time window aggregation to achieve precise dimensionality reduction of massive logs. This allows subsequent fault analysis to focus only on log slices highly relevant to the fault, significantly reducing the amount of data processing while ensuring the integrity and correlation of asynchronous logs across modules, thus improving analysis efficiency.

[0088] In some embodiments, when the electronic device determines the corresponding fault event information based on the above-mentioned multiple second fault information, it does not send all the second fault information extracted in time and space to the subsequent hierarchical fault identification stage, but first performs a round of fast screening based on the hardware layer.

[0089] Optionally, the electronic device can detect whether there are hardware resource abnormality-related features (e.g., CPU overload, memory leak, sensor timeout, etc.) in each second fault information. If a second fault information matches the above-mentioned hardware abnormality features, the second fault information is directly marked as root cause fault event information, and this information will bypass the subsequent hierarchical fault identification process and enter the report generation stage; if a second fault information does not match any hardware abnormality features, it is treated as fault event information to be identified at the next level for further analysis.

[0090] Optionally, based on the fault category identifier of the second fault information, the electronic device queries a preset category priority table to directly mark high-priority fault categories (e.g., system-level resource exhaustion) as root causes, while other categories proceed to subsequent levels of identification. In this way, some definitive faults can be pre-selected, reducing the computational burden on subsequent levels of identification.

[0091] S203. Based on the preset rule base, perform hierarchical fault identification on fault event information and determine the causal information chain corresponding to each fault event information.

[0092] A pre-defined rule base can refer to a set of pre-defined knowledge rules that includes fault hierarchy classification and upstream / downstream propagation relationships between levels. The rule base defines the mapping relationship between each fault category and fault level, as well as the direction and conditions of fault propagation between levels.

[0093] A causal information chain can refer to structured data that indicates the complete propagation path of a fault from the root cause level to the final manifestation level. The causal information chain contains the chronological order of fault events at each level of the propagation chain and their upstream and downstream dependencies, ultimately pointing to a unique root cause level.

[0094] In some embodiments, based on the identified fault event information, the electronic device performs hierarchical fault identification on the fault event information according to a preset rule base, so as to eliminate apparent faults, trace the root cause hierarchy, and finally generate a causal information chain containing the fault propagation path.

[0095] For example, each fault event information is first mapped to the corresponding level in the preset fault level model according to its fault category. Then, starting from the bottom level, the fault event information is traced upwards layer by layer to determine whether there is any associated fault event information in the previous level. If there is, the tracing continues upwards until there is no associated fault event information in the previous level. At this point, the level is the root cause level. The root cause level and the fault events of each level that it passes through are output as a causal information chain.

[0096] S204. Based on the information of each fault event and the corresponding causal information chain, determine multiple target fault root causes, and generate a vehicle fault report based on the multiple target fault root causes.

[0097] A target root cause can refer to one or more root causes that are selected from multiple root cause candidates and ranked highly according to a preset scoring mechanism. A target root cause should include at least the root cause level, fault category, confidence level, and key information.

[0098] Fault reports can refer to structured or semi-structured diagnostic results output, including core fields such as fault summary, root cause analysis, evidence log list, and repair suggestions, which are used by users to quickly obtain analysis conclusions and the basis for subsequent processing.

[0099] In some embodiments, the electronic device determines the hierarchical weight and event weight of each fault event information based on the aforementioned causal information chain, and calculates the root cause score of each fault event information according to a preset weighted scoring formula, based on the influence range and repairability index of each fault event information, and selects a preset number of fault event information as the target fault root cause after sorting according to the root cause score.

[0100] After identifying the root cause of the target fault, the electronic device retrieves historical fault cases and repair solutions that match the target fault root cause from a preset knowledge base. It integrates the target fault root cause and its corresponding causal information chain, historical matching cases and repair suggestions into structured data, and generates a fault analysis report in a preset format based on this. It also automatically creates a problem ticket and synchronizes the problem description, analysis conclusion and repair suggestions to the relevant business systems.

[0101] In this embodiment, first fault information containing descriptive information and the time period of occurrence is obtained. Multiple second fault information is obtained by spatiotemporal extraction of the first fault information based on the descriptive information and the time period of occurrence. Corresponding fault event information is determined based on the multiple second fault information. Hierarchical fault identification is performed on the fault event information according to a preset rule base to determine the causal information chain corresponding to each fault event information. Multiple target fault root causes are determined based on each fault event information and its corresponding causal information chain. A fault report is generated based on the multiple target fault root causes. In this method, electronic devices can determine the target fault root causes by performing spatiotemporal extraction and hierarchical fault identification on fault information, combined with causal reasoning. This enables rapid location of the root cause in massive fault logs, effectively avoiding the problems of root cause misjudgment and location bias that exist in manual analysis, improving analysis efficiency, accurately determining the root cause of vehicle faults, and being applicable to the fault diagnosis needs of different autonomous driving systems. It reduces expert dependence and improves fault handling efficiency while increasing fault location accuracy.

[0102] Based on any of the above embodiments, the following, in conjunction with Figure 3 The process of determining the corresponding fault event information based on multiple second fault information is explained in detail.

[0103] Figure 3 This is a schematic diagram illustrating the process of determining fault event information provided in an embodiment of this application. Please refer to [link / reference]. Figure 3 The method may include:

[0104] S301. Determine whether there is a hardware fault in each of the second fault information.

[0105] Hardware failure can refer to anomalies occurring in the underlying physical resources or core hardware devices of an autonomous driving system. For example, hardware failures may include, but are not limited to, CPU overload, memory leaks, and sensor malfunctions.

[0106] CPU overload refers to a persistently high length of the CPU's run queue. Specifically, this manifests as an average number of processes (Load Average) in the run queue exceeding twice the number of CPU cores, and this state persists for three sampling periods (each sampling period is typically on the order of seconds) without recovery, indicating a resource contention state. In this state, processes in various modules cannot obtain sufficient CPU time slices for normal computation, leading to task response delays or even timeouts.

[0107] A memory leak occurs when an application fails to properly release dynamically allocated memory after use, leading to a continuous decrease in available system memory. For example, if the actual system memory usage exceeds the upper limit of the confidence interval predicted based on historical data, and the memory usage shows a monotonically increasing trend (i.e., only increasing and not decreasing), critical processes may be forcibly terminated by the operating system due to the inability to allocate memory.

[0108] Sensor anomalies refer to timestamp synchronization disorders in environmental perception sensors such as LiDAR, cameras, and millimeter-wave radar. For example, this can manifest as timestamp rollback, where the timestamp of a later frame is less than the timestamp of a previous frame, indicating a reset of the sensor's internal clock or out-of-order data in the data buffer.

[0109] In some embodiments, the electronic device determines whether there is a hardware fault in each second fault information by calling a preset hardware root cause detector for each second fault information.

[0110] Specifically, taking three types of detectors as an example, the first type is the CPU overload detector. The electronic device reads the system load data from the second fault information and determines whether the Load Average exceeds twice the number of CPU cores and lasts for three sampling cycles. If the above conditions are met, it is marked as a CPU resource contention type hardware fault.

[0111] The second type is the memory leak detector. The electronic device reads the memory usage data from the second fault information and determines whether the actual memory value exceeds the upper limit of the predicted confidence interval and whether the memory usage shows a monotonically increasing trend. If the above conditions are met, it is marked as a memory leak type hardware fault.

[0112] The third type is the sensor synchronization detector. The electronic device reads the message timestamps of each sensor in the second fault information and checks for timestamp rollback (the timestamp of the later frame is less than that of the previous frame) or the time difference between adjacent messages exceeding twice the standard frame interval. If any of the above conditions are met, it is marked as a sensor abnormal hardware fault. If none of the above three types of detectors are detected, it is determined that there is no hardware fault in the second fault information.

[0113] S302. When a hardware fault exists in the second fault information, the second fault information is processed by timing to obtain fault event information.

[0114] In some embodiments, the second fault information can be processed in a time sequence to obtain fault event information by: filtering the second fault information according to a preset time window to obtain multiple adjacent fault events; sorting and reorganizing the multiple adjacent fault events to obtain fault event information.

[0115] The preset time window can refer to a fixed duration interval used to constrain the time series filtering range; for example, it can be set to 100ms. This window is used to aggregate asynchronous log events belonging to different modules that occur within the same physical time window into a single group.

[0116] It should be noted that this window is different from the time window (time_window_ms) used for spatiotemporal extraction in S202: the time window in S202 expands bidirectionally before and after the timestamp of the fault trigger point, and is used to initially extract log fragments that may be related to the fault from the original logs; while the time window in S302 is a fixed unidirectional window, used to further refine the causal relationship between modules in the distributed system based on the second fault information that has been initially screened. Therefore, the two have different uses and window lengths.

[0117] Proximity fault events can refer to a set of fault events that are closely adjacent in the time dimension, that is, multiple fault events whose timestamps are located within the same preset time window.

[0118] In some embodiments, the electronic device filters the second fault information according to a preset time window to obtain multiple adjacent fault events in the following way: the electronic device determines the timestamp of each fault event in the second fault information, and then groups all fault events according to the preset time window, and divides the fault events whose timestamps belong to the same time window into a group to obtain multiple adjacent fault event groups.

[0119] During this process, the electronic device will also assign weights to events based on the fault category identifier. That is, for each fault event, the electronic device will trace back to the predecessor event and calculate the timestamp difference between the two. The larger the difference, the smaller the weight of the event.

[0120] In some embodiments, the electronic device sorts and reorganizes multiple adjacent fault events in the following manner: the electronic device sorts the adjacent fault events according to the order of their timestamps to form a set of time-series execution flows grouped and sorted by module ID. The specific format can be represented as: Fault event information = {Module ID_1: [Event 1, Event 2, ..., Event N], Module ID_2: [Event 1, Event 2, ..., Event M], ...}.

[0121] The structure of each event is as follows: Event = {Predecessor Event: Predecessor event identifier (empty if there is no predecessor), Fault Category: Fault category identifier, Weight: Event weight (floating-point number between 0 and 1), Timestamp: Event occurrence time, Context Information: Log context associated with the event}.

[0122] The above method can aggregate cross-module asynchronous events occurring within the same physical time window into the same group, and sort and reorganize the events according to their time sequence, effectively solving the causal misalignment problem caused by clock drift and log scattering in distributed systems, and providing accurate event sequence input for subsequent hierarchical fault identification.

[0123] In this embodiment, by determining whether each second fault information contains a hardware fault, and when a hardware fault is found, the second fault information is filtered according to a preset time window to obtain adjacent fault events, and the adjacent fault events are sorted and reorganized to obtain fault event information. This method can quickly locate the hardware root cause of second fault information with hardware anomalies, avoiding the computational overhead caused by sending all irrelevant logs and fault event information into subsequent hierarchical identification processes. Simultaneously, the time window filtering and sorting / reorganization ensure the complete temporal correlation of adjacent fault events, improving the accuracy and processing efficiency of fault event information determination.

[0124] Based on any of the above embodiments, the following, in conjunction with Figure 4 The process of identifying hierarchical faults based on a preset rule base and determining the causal information chain corresponding to each fault event is explained in detail.

[0125] Figure 4 This is a schematic diagram illustrating the process of determining the causal information chain provided in the embodiments of this application. Please refer to... Figure 4 The method may include:

[0126] S401. For any fault event information, traverse each fault level in the rule base layer by layer to see if there is a corresponding fault event information, until it is determined that there is no corresponding fault event information, and then determine the current fault level as the root cause level.

[0127] In some embodiments, the hierarchical structure of the rule base is pre-built based on the physical mechanism of fault propagation in autonomous driving systems, and is used to represent the location of each fault category in the system and the transmission relationship of faults between different levels.

[0128] For example, the rule base contains seven fault levels, from bottom to top: performance resource layer (L0), hardware device layer (L1), driver configuration layer (L2), algorithm function layer (L3), fusion decision layer (L4), planning decision layer (L5), and control execution layer (L6). Faults at lower levels can propagate to higher levels and trigger faults at those levels; that is, faults at any level can potentially become the cause of faults at the level above.

[0129] For example, the hierarchical structure of the rule base can be shown in Table 1:

[0130] Table 1

[0131]

[0132] The performance resource layer (L0) includes fault categories such as MEMORY_OOM (memory exhaustion), CPU_HIGH (sustained high CPU load), MEMORY_LEAK (memory leak), and SYSTEM_LOAD_HIGH (excessive system load). This layer is located at the top of the propagation chain and is the starting point for fault propagation. When it acts as the root cause, it can lead to faults in all upper layers from L1 to L6. The physical mechanisms are as follows: when system-level resources are exhausted, it triggers the process killing mechanism to forcibly terminate processes, or causes CPU starvation, preventing critical tasks from being executed for a long time, and hardware delays or timeouts due to the inability to obtain timely CPU responses.

[0133] Fault categories at the hardware device layer (L1) include CAMERA_TIMEOUT (camera data timeout), IMU_RANGE_ERROR (inertial measurement unit range error), CANBUS (controller area network bus communication error), and SENSOR (sensor general error). This layer can be a direct victim of performance resource layer faults (hardware response timeout due to resource starvation) or an upstream cause of driver configuration layer faults in the propagation chain. When it acts as the root cause, it can lead to L2 driver layer initialization failure or bypass the driver layer to directly prevent the L3 perception algorithm functional layer from acquiring valid perception data. The physical mechanism is: the physical device itself malfunctions or experiences a response timeout, resulting in data stream interruption.

[0134] Fault categories in the Driver Configuration Layer (L2) include MODULE_CRASH (module crash), PROTO_CONFIG_ERROR (protocol configuration error), and LITE_CONFIG_ERROR (lightweight configuration error). This layer is downstream of the hardware device layer and upstream of the algorithm function layer in the propagation chain; it is both the receiver of hardware problems and the trigger for algorithm malfunctions. When it acts as the root cause, it can cause the L3 sensing or detection module to fail to start normally or to exit abnormally during operation. The physical mechanism is: driver initialization failure, configuration file parsing errors, or incompatibility between software versions, causing the underlying hardware to be unable to provide normal service interfaces to the upper-layer algorithm.

[0135] Fault categories in the algorithm functional layer (L3) include PERCEPTION (perception anomaly) and DETECTION_TRACKING (detection and monitoring anomaly). This layer, located downstream of the driver configuration layer and upstream of the fusion decision layer in the propagation chain, is responsible for processing raw sensor data and outputting target detection results. When it acts as a root cause, it can lead to missing or degraded input data for the L4 fusion decision layer. The physical mechanism is as follows: algorithm processing anomalies render the output target position, velocity, category, and other information invalid, or the algorithm's processing frame rate drops significantly, failing to meet real-time requirements.

[0136] Fault categories in the fusion decision layer (L4) include FUSION (multi-sensor fusion anomaly). This layer, located downstream of the algorithmic functional layer and upstream of the planning decision layer in the propagation chain, is responsible for fusing information from multiple sensor sources to form a unified environmental model. When it acts as a root cause, it can increase the input uncertainty of the L5 planning decision layer. The physical mechanisms are: monitoring loss during multi-sensor fusion, failure of temporal or spatial synchronization between different sensors, or drift in localization results.

[0137] Fault categories in the planning decision layer (L5) include PLANNING (planning anomaly) and PLANNING_TASK (planning task anomaly). This layer, located downstream of the fusion decision layer and upstream of the control execution layer in the propagation chain, is responsible for generating the vehicle's trajectory based on the environmental model and location information. When it acts as a root cause, it can lead to the L6 control execution layer failing to generate effective control commands or experiencing command delays. The physical mechanisms are: trajectory generation failure, no optimization solution, and constraint conflicts.

[0138] The fault categories in the control execution layer (L6) include CONTROL (control anomaly), CONTROL_OUT_OF_CONTROL (control failure), and CONTROL_SOLVER (control solution anomaly). This layer is located at the end of the propagation chain and is the final output of the fault. When it is the root cause, there are no downstream layers (or feedback to the system monitoring layer). Its physical mechanism is: the control command fails to execute when it is sent to the chassis, or the chassis responds abnormally to the command, or the vehicle safety monitoring module is triggered due to the detection of an abnormal state.

[0139] It's important to note that the same fault level can play different roles in different scenarios: some levels may act as independent root causes, or they may be victims of faults at lower levels. For example, the performance resource layer (L0) is at the top of the propagation chain, and as the starting point of the propagation chain, it may cause system-wide faults. The hardware device layer (L1) may be an independent root cause (i.e., a real physical fault), or it may be a victim of a performance resource layer (L0) fault (resource starvation leading to hardware response timeouts), and other layers are similar.

[0140] Therefore, during the hierarchical traversal process, electronic devices first verify L0 layer indicators through the hierarchical penetration algorithm to eliminate performance problem disguises, and perform root cause penetration identification based on the propagation chain.

[0141] S402. Generate a causal information chain based on the root cause hierarchy.

[0142] In some embodiments, a hierarchical penetration algorithm can be used to generate a causal information chain. Specifically, after the electronic device traverses layer by layer through S401 and determines the root cause level, it needs to construct the complete propagation path of the fault based on the root cause level. The electronic device uses the root cause level as the starting point of the propagation chain and searches for the existence of corresponding fault event information in each level from bottom to top along the hierarchical model.

[0143] If a corresponding fault event information exists at a certain level, the fault event at that level is recorded as a node in the propagation chain and the search continues to the next level. If a corresponding fault event information does not exist at a certain level, the search stops, indicating that the propagation chain terminates at the level below that level (i.e., the end of the propagation chain).

[0144] The electronic device arranges all recorded fault event nodes in order from the bottom layer to the top layer, forming a complete fault causal propagation chain. For example, if the hierarchical penetration algorithm determines that L0 (performance resource layer) is the root cause layer, the electronic device starts searching upwards from L0. If L1 has corresponding fault event information, the L1 fault event is added to the propagation chain; if L2 also exists, it continues to be added; until a certain layer is found to have no corresponding fault event.

[0145] The resulting causal information chain includes the starting point (root cause level), the ending point (final manifestation level), and the fault events at each level along the way, providing a complete description of the entire transmission process of the fault from its inception to its final manifestation.

[0146] Below, in conjunction with Figure 5 The process of hierarchical fault identification is explained in detail.

[0147] Figure 5 This is a schematic diagram illustrating the hierarchical fault identification process provided in an embodiment of this application. Please refer to... Figure 5 This method can include three stages: fault classification, upward tracing, and root cause confirmation. In the fault classification stage, the electronic device maps all fault event information identified in S302 to the corresponding fault level in a preset rule base according to their fault category identifier, and labels the position attribute of each fault event information in the fault propagation hierarchy model. In the upward tracing stage, the electronic device traces upwards layer by layer from the level to which the current fault event information belongs, checking whether there is a corresponding fault event information in each preceding fault level: if it exists, the current fault event information is marked as a apparent fault, and upward tracing continues; if it does not exist, tracing stops. In the root cause confirmation stage, based on the upward tracing results, the electronic device confirms the fault event information that was not marked as an apparent fault as the root cause level after penetration and its corresponding fault event information, as the final output of the entire fault diagnosis process.

[0148] In this embodiment, for any fault event information, the system iterates through each fault level in the rule base to check for corresponding fault event information until it is determined that no corresponding fault event information exists. At this point, the current fault level is identified as the root cause level, and a causal information chain is generated based on the root cause level. This method enables bottom-up, penetrating tracing of fault events through a hierarchical traversal mechanism. In cases of multi-level cascading faults, it accurately identifies the root cause level rather than focusing on superficial faults. This effectively avoids root cause misjudgments and location errors caused by experience differences in manual analysis, thus improving the accuracy of vehicle fault determination.

[0149] Figure 6 This is a flowchart illustrating a method for determining multiple target fault root causes provided in an embodiment of this application. Please refer to... Figure 6 The method may include:

[0150] S601. Based on the pre-trained language model, information on each fault event, and the corresponding causal information chain, determine multiple candidate root causes of the fault.

[0151] Pre-trained language models are used for semantic understanding and causal reasoning in complex scenarios that rule engines cannot cover, such as large language models (LLM).

[0152] Candidate root causes of failures refer to one or more possible fault cause candidates output by a pre-trained language model after semantic understanding and reasoning based on the input fault event information and causal information chain. Each candidate root cause contains information such as root cause description, confidence level indicator, and key evidence, which are used for subsequent weighted scoring and screening.

[0153] In some embodiments, the electronic device determines multiple candidate root causes of faults based on a pre-trained language model, information on each fault event, and the corresponding causal information chain in the following way: The electronic device can construct a structured causal graph based on the causal information chain. This causal graph uses fault events as nodes and upstream and downstream propagation relationships between levels as edges, reflecting the complete transmission path of the fault from the root cause level to the final manifestation level. The electronic device takes the structured causal graph and the original log context (fault event information) as input, constructs structured input data according to a preset prompt word template, replaces each placeholder in the preset prompt word template with the actual fault information, for example, replaces {description} with the user's problem description, replaces {module_name} with the name of the currently analyzed module, replaces {content} with the module log content, and fills in root cause analysis guidance information (root_cause_guidance) to generate complete large model input prompt words.

[0154] Then, the electronic device inputs the constructed prompts into a pre-trained language model. Under pre-defined role constraints (e.g., you are a professional autonomous driving system log analysis expert), the pre-trained language model performs semantic understanding and root cause analysis on the input fault information. During the analysis process, the pre-trained language model needs to check each item: time verification, module responsibility verification, evidence sufficiency verification, and causal relationship analysis. Each causal relationship must be supported by specific log evidence, and the temporal sequence of causal relationships must match. For faults in the logical causal layer that fail rule verification due to rule coverage limitations, faults with conflicting markers such as cyclic causality or priority reversal, faults with causal edge confidence below a threshold, and scenarios where fault messages contain complex natural language descriptions requiring semantic parsing, the pre-trained language model performs in-depth analysis using its semantic understanding capabilities and provides an arbitration judgment.

[0155] Only after passing all validations will the pre-trained language model output structured root cause analysis results, which include: semantic causal edges (causal relationship edges after semantic verification and supplementation by the large model), arbitration results (judgment conclusions on conflict markers), and multiple candidate root causes of failure; if validation fails, structured information on validation failure will be output. Finally, the electronic device parses the structured text output by the pre-trained language model to obtain multiple candidate root causes of failure, each carrying a corresponding confidence level indicator and key evidence log.

[0156] S602. Among multiple candidate root causes of failure, identify multiple target root causes of failure.

[0157] In some embodiments, multiple target root causes can be determined from multiple candidate root causes in the following manner: determining the event weight, hierarchy weight, scope weight, and repair weight corresponding to each candidate root cause; calculating the fault score of each candidate root cause based on the event weight, hierarchy weight, scope weight, and repair weight; and obtaining multiple target root causes based on the fault scores.

[0158] Event weight, denoted as EventWeight, is a quantitative metric used to measure the degree of connection between a failure event and its predecessor events in a temporal causal chain. A higher event weight indicates a stronger temporal correlation between the event and its predecessor events, and a greater likelihood that the event was directly triggered by the predecessor events.

[0159] In some embodiments, the event weight can be a weight value calculated and labeled for each fault event. The weight decreases as the difference between the timestamp of the event and its predecessor event increases. The physical meaning is: the shorter the time interval between two events, the higher their weight, and the more likely they are to form a direct causal relationship; conversely, the longer the time interval, the lower the weight.

[0160] Level weight refers to a quantitative indicator used to indicate the position of a candidate root cause in a preset fault propagation hierarchy model, denoted as LevelWeight. A higher level weight indicates that the fault is closer to the bottom layer in the propagation chain (closer to the performance resource layer), and is more likely to be the true root cause rather than a superficial fault. In this embodiment, the level weight can be determined by the fault level (L0 to L6) mapped to the fault event information, where L0 (performance resource layer) has the highest level weight, and L6 (control execution layer) has the lowest level weight.

[0161] The scope weight, denoted as Impact, is a quantitative indicator used to measure the magnitude of the impact range of a candidate root cause of a fault. The impact range includes horizontal impact (the number of modules affected within the same level) and vertical impact (the number of levels traversed in the downstream propagation). A higher scope weight indicates a wider impact of the fault and makes it more worthy of priority handling. In this embodiment, the impact range is determined by the number of fault events included in the fault propagation chain; the longer the propagation chain and the more modules involved, the larger the impact range.

[0162] Fixability refers to a quantitative metric, denoted as Fixability, used to measure the ease with which a candidate root cause of a fault can be fixed. A higher fixability indicates that the fault is easier to fix (e.g., it can be quickly recovered by adjusting configuration parameters or restarting the process), while a lower fixability indicates greater difficulty in fixing (e.g., requiring modification of the core algorithm code). For example, fixability can be determined by a preset fixability level corresponding to the fault category.

[0163] Fault score refers to a multi-dimensional weighted score used to comprehensively evaluate the severity and priority of each candidate root cause of a fault. The higher the fault score, the higher the credibility of the root cause, the greater its impact, and the more it should be prioritized for treatment.

[0164] In some embodiments, after determining the event weight, hierarchical weight, scope weight, and repair weight corresponding to each candidate fault root cause, it is necessary to determine the corresponding adjustment coefficients. These adjustment coefficients are then used to determine the fault score. Specifically, the adjustment coefficients are correction factors determined based on factors such as the environmental complexity of the fault scenario, module coupling, and fault recurrence probability, and are used to dynamically adjust the four types of weights. For example, for faults occurring during the system startup phase, since the modules are in an initialization state and have complex dependencies, the hierarchical weights can be multiplied by a larger adjustment coefficient to highlight the priority of lower-level faults. For faults occurring during the stable operation phase, the default adjustment coefficients can be maintained. The adjustment coefficients can be preset fixed values ​​or values ​​dynamically calculated based on the fault scenario.

[0165] In some embodiments, the electronic device calculates the fault score for each candidate root cause based on event weight, hierarchy weight, scope weight, and repair weight as follows: The electronic device multiplies the event weight, hierarchy weight, scope weight, and repair weight corresponding to each candidate root cause by their respective adjustment coefficients, and then determines the weighted sum as the fault score. The relevant formula for the fault score can be expressed as follows:

[0166]

[0167] Among them, A, B, C, and D are preset weight coefficients, which respectively represent the proportion of the level weight, event weight, scope weight, and repair weight in the total score.

[0168] For example, suppose A=0.35, B=0.30, C=0.20, and D=0.15. Among them, the hierarchical weight has the largest proportion, reflecting the engineering principle of prioritizing the underlying faults, that is, the closer the fault is to the beginning of the propagation chain, the more likely it is to be the real root cause. The event weight is the second largest, reflecting the importance of the temporal correlation to the causal judgment. The scope weight and the repair weight are used as auxiliary dimensions to refine the ranking among multiple candidate root causes, ensuring that the scoring results have both causal rationality and engineering practicality.

[0169] In some embodiments, the electronic device obtains multiple target root causes of faults based on fault scores in the following manner: The electronic device sorts all candidate root causes of faults in descending order of fault scores. Then, the electronic device selects a target root cause of fault from the sorted results according to a preset selection rule. The selection rule may include, but is not limited to, the following: determining candidate root causes of faults with fault scores exceeding a preset threshold as target root causes of faults; or selecting a preset number of candidate root causes of faults as target root causes in descending order of sorting, for example, selecting the top K with the highest scores (K is a preset positive integer, for example, 3). The selected target root causes of faults serve as the final output of the entire root cause analysis process and are used to generate a fault report.

[0170] By employing the above methods, large models and multi-dimensional weighted scoring mechanisms are used to quantitatively rank the root causes of the selected cases. This effectively avoids root cause misjudgments and positioning biases caused by differences in experience during manual analysis. It also solves the problems of pure rule engines lacking the ability to analyze complex natural language descriptions and the strong randomness and uninterpretability of the output results of pure large model solutions, thereby improving the accuracy and efficiency of vehicle fault determination.

[0171] In this embodiment, a pre-trained language model determines multiple candidate root causes of faults based on fault event information and corresponding causal information chains. Then, by determining the event weight, hierarchy weight, scope weight, and repair weight corresponding to each candidate root cause and calculating a fault score, multiple target root causes are obtained through screening based on the fault scores. This method leverages the semantic understanding capabilities of the pre-trained language model to supplement the analysis of complex scenarios that rule engines struggle to cover. Furthermore, it quantifies and ranks the candidate root causes through a multi-dimensional weighted scoring mechanism, effectively avoiding root cause misjudgments and positioning biases caused by experience differences in manual analysis. This solves the problems of pure rule engines lacking the ability to parse complex natural language descriptions and the strong randomness and uninterpretability of output results from pure large-scale model solutions, thus improving the accuracy and processing efficiency of vehicle fault determination.

[0172] Figure 7 This is a flowchart illustrating a method for determining multiple target fault root causes provided in an embodiment of this application. Please refer to... Figure 7 The method may include:

[0173] S701. Search the preset knowledge base to obtain historical fault cases that match the root cause of the target fault.

[0174] A pre-built knowledge base can refer to a structured knowledge repository that is pre-built to store historical failure cases, expert experience rules, and technical documents.

[0175] Historical failure cases refer to records of failure events within a historical period that have undergone root cause identification and remediation. Each historical failure case contains structured fields such as failure fingerprint, root cause type, failure level, remediation plan, and effectiveness score, as well as a complete failure analysis process and remediation record.

[0176] In some embodiments, before retrieving data from the knowledge base, the target fault root cause needs to be subjected to defect fingerprint distillation processing, which converts it into a structured, deduplicated, and highly condensed defect fingerprint object, which serves as the index key for knowledge base retrieval.

[0177] The processing flow of the defect fingerprint distiller is as follows: the target fault root cause is used as the input layer data. First, JSON is parsed in the parsing layer to extract the selected_modules_evidence field, which contains all module-level evidence information related to the fault root cause. Then, the processing layer processes each module (_process_module_result), which includes four processing sub-steps: (1) Module extraction (_extract_modules), extracting all involved module names from the evidence; (2) Summary extraction (_extract_summaries), using a lightweight natural language processing model to compress large sections of error logs. (3) Log pattern retrieval and wildcard matching (_extract_log_patterns), replace the variable part in the specific error line with wildcards, and extract the log skeleton; (4) Key value extraction (_extract_key_values), capture numerical indicators (e.g., CPU utilization, memory usage, etc.); call the _finalize_fingerprint function in the aggregation layer to deduplicatize and merge the results of the four dimensions output by the processing layer and sort them; finally, output the defect fingerprint object containing modules, summaries, log_patterns and key_values ​​in the output layer.

[0178] The core field groups of the knowledge base include the index layer, fault signature layer, diagnostic process layer, repair solution layer, effect evaluation layer, and retrieval statistics layer. The system comprises the following layers: an index layer containing a fingerprint field as the key for vector retrieval; a fault signature layer containing two fields, root_cause_type (root cause classification retrieval) and hardware_context (structured hard filtering conditions), used for quickly filtering similar faults; a diagnostic process layer containing two fields, automated_analysis (automated analysis process record) and human_verification (human verification mark, used to improve credibility), recording the complete fault diagnosis process; a remediation solution layer containing three fields, immediate_action (emergency damage mitigation plan), root_fix (root solution, including configuration change details), and recurrence_prevention (long-term preventive measures), providing hierarchical remediation suggestions; an effectiveness evaluation layer containing two fields, effectiveness_score (case quality score, low-scoring cases are downgraded or removed) and follow_up_records (tracking verification records, supporting continuous learning), used for continuously evaluating the quality of knowledge base cases; and a retrieval statistics layer containing retrieval_count (popular case identification, used to optimize caching strategies) and average_similarity_score (retrieval accuracy feedback), used to optimize retrieval efficiency.

[0179] For example, the overall structure of the knowledge base can be shown in Table 2:

[0180] Table 2

[0181]

[0182] In some embodiments, the electronic device performs knowledge base retrieval as follows: the electronic device uses the defect fingerprint object generated by processing the target fault root cause through a defect fingerprint distiller as the retrieval input, calculates the similarity between the defect fingerprint vector and the fingerprint vectors of each historical fault case in the knowledge base (e.g., using cosine similarity or Euclidean distance metric), and returns all historical fault cases with similarity higher than a preset threshold as retrieval results. When returning retrieval results, the electronic device sorts the historical fault cases in descending order of similarity and selects a preset number of cases with the highest similarity (e.g., the top K cases with the highest similarity, where K is a preset positive integer) as matching historical fault cases.

[0183] S702. Generate a fault report based on the pre-trained language model, historical fault cases, and target fault root causes.

[0184] In some embodiments, the electronic device generates a fault report based on a pre-trained language model, historical fault cases, and the target fault root cause in the following way: the electronic device constructs a pre-trained language model for prompt word input by combining one or more historical fault cases retrieved in S701 with the target fault root cause of the current fault.

[0185] The electronic device fills the current fault characteristics, repair solutions for historical fault cases, and experience rules into the corresponding positions of the preset prompt word template. The current fault characteristics include the defect fingerprint matching degree (similarity score), root cause type, propagation chain, affected modules, and operating environment information. The historical fault cases include repair solutions for similar cases retrieved from the knowledge base. It also includes expert experience rules and technical document fragments extracted from the knowledge base.

[0186] After receiving the above input, the pre-trained language model analyzes the current failure based on the repair experience in historical failure cases, and generates a structured failure report that includes an execution summary, root cause analysis, immediately actionable repair suggestions (e.g., temporary workarounds and long-term solutions), and preventive suggestions.

[0187] For example, the prompt template can be configured with a large model acting as a senior expert in autonomous driving system problem analysis. Based on retrieved similar cases and expert knowledge, it generates an executable repair solution for the current fault. The template structure includes four input parts: current fault characteristics, similar historical cases, expert experience rules, and technical document references, as well as output requirements. The current fault characteristics include defect fingerprint matching degree, root cause type, causal information chain, affected modules, operating environment version, and platform information. Similar historical cases are a preset number of historical fault cases most similar to the current fault returned by the retrieval. Expert experience rules are structured judgment rules stored in the knowledge base. Technical document references are matching text fragments retrieved from pre-entered system design documents. The output requirements specify the fields and format that the generated report should include.

[0188] As can be seen, this application introduces Retrieval-Augmented Generation (RAG) technology. This technology involves defect fingerprint distillation of the target fault root cause and its related feature information, converting it into a structured fingerprint vector. Matching historical fault cases and their repair solutions are then retrieved from a pre-defined knowledge base. Finally, leveraging the semantic understanding and generation capabilities of a large model, the retrieval results are fused with the current fault context to generate actionable repair suggestions. Through this method, electronic devices, based on accurate fault root cause location, further provide evidence-based and traceable repair solutions. This effectively avoids the problems of inaccurate repair solutions or omissions of key repair steps due to insufficient human experience, improving the efficiency of fault handling and the credibility of repair suggestions.

[0189] The electronic device outputs the fault report in a readable format (e.g., HTML) and automatically creates a problem ticket via an API interface, synchronizing the problem description, analysis conclusions, and repair suggestions to the business system. Finally, the electronic device pushes the fault report to technical personnel, helping them quickly obtain analysis conclusions and a basis for subsequent processing.

[0190] Below, in conjunction with Figure 8 The process for handling fault reports is explained in detail.

[0191] Figure 8 This is a schematic diagram illustrating the fault report processing procedure provided in an embodiment of this application. Please refer to... Figure 8 This includes: electronic devices taking module-level results (including at least root cause hierarchy, causal propagation chain, evidence log list, scores of each fault event, etc.) and RAG scheme results (i.e. fault reports) as input data for the input layer; in the data fusion layer, the module-level analysis results and RAG scheme results are aligned with multi-source information, deduplicated, and prioritized; information from different processing stages is integrated according to a unified field mapping relationship; duplicate or redundant fault evidence is removed; and the display priority of each fault root cause is determined according to the fault score ranking results.

[0192] Electronic devices create visual fault analysis reports based on preset report templates, filling in fault summaries, root cause analysis, evidence log lists, causal propagation chains, and remediation suggestions in the corresponding positions of the templates. They also automatically create issue tickets based on preset issue ticket templates, mapping issue descriptions, analysis conclusions, and remediation suggestions to custom fields in the system. Furthermore, they push fault analysis conclusions and processing tasks to technical personnel based on collaborative notification templates. In the closed-loop feedback layer, electronic devices synchronize the status and track the effects of created issue tickets. When the status of an issue ticket changes (e.g., from pending to under repair or resolved), the electronic device receives a status change callback and updates its local records. Simultaneously, it tracks and verifies the remediation effect, incorporating the feedback data after remediation into the knowledge base for continuous optimization.

[0193] In this embodiment, historical fault cases matching the target fault root cause are retrieved from a preset knowledge base, and a fault report is generated based on a pre-trained language model, historical fault cases, and the target fault root cause. This method solidifies historical fault handling experience into the knowledge base in the form of cases. When a new fault occurs, similar cases and their repair solutions are retrieved, allowing direct reuse of historical experience to guide the handling of the current fault. This avoids the need to analyze each fault from scratch. Furthermore, the generated fault report includes both current fault root cause analysis and historical case repair suggestions, providing technicians with traceable analytical basis. This effectively avoids inaccurate or incomplete repair solutions caused by insufficient experience or memory bias in manual analysis, improving fault handling efficiency and the convenience of experience reuse while enhancing fault location accuracy.

[0194] Figure 9 This is a flowchart illustrating another method for determining vehicle faults provided in an embodiment of this application. Please refer to... Figure 9 The method may include:

[0195] S901, Multimodal Input and Preprocessing.

[0196] The electronic device acquires the first fault information during vehicle operation, including a description and the time of occurrence. The device supports importing fault data in various formats, including automatic downloading or importing issues using offline log packages, problem tickets, or real-time streaming data.

[0197] S902, Parallel semantic cleaning.

[0198] By parsing log files and performing semantic cleaning in parallel, the context and tracking information of all module failures within a specified time period can be obtained.

[0199] S903, Initial screening of hardware root causes.

[0200] Specifically, it checks the log files to see if any hardware issues such as CPU overload, memory overrun, or sensor malfunctions have occurred.

[0201] S904, a module-level causal reasoning engine.

[0202] Specifically, by adopting a two-layer architecture of rule pre-screening and large model fine inference, it is responsible for the transformation from raw log information to structured causal knowledge. Its technical goals include reconstructing the timeline of fault evolution in a single-threaded dimension, identifying causal relationships within and across threads, and generating interpretable root cause candidates.

[0203] Its technical architecture includes a four-layer causal modeling system: the first layer is the time-series causal layer, which takes the original log event stream (second fault information) as input, sorts the events in the thread, searches for candidate predecessor events according to causal relationships within the time window to reconstruct the event stream, and marks the event weight. The larger the timestamp difference, the smaller the weight, in order to solve the problem of time misalignment of faults in distributed systems and output time clusters (fault event information).

[0204] The second layer is the logical causal layer, which takes time clusters and rule bases as inputs. It verifies the rationality of causal relationships between modules through a rule engine, and uses a hierarchical penetration algorithm to prioritize the verification of L0 layer indicators to eliminate performance problem disguises. It performs root cause penetration identification based on causal information chains and outputs verified causal edges, unexplained faults, and conflict markers.

[0205] The third layer is the large model semantic enhancement layer. It takes the structured causal graph and the original context as input, and improves, verifies and supplements the causal inference through the semantic understanding ability of the large model. It handles complex scenarios that the rule engine cannot cover (e.g., no clear causal relationship, circular causality, confidence level below the threshold, containing complex natural language descriptions, etc.), and outputs semantically clear, logically reasonable and structured root cause candidate results.

[0206] The fourth layer is the root cause decision layer, which takes the causal graph and root cause candidates as input and integrates the fragmented causal evidence generated by the previous layers into a list of root cause candidates that can be sorted, explained, and acted upon, i.e., multiple candidate root causes of failure.

[0207] S905, Search Enhancement Generation Analysis.

[0208] Specifically, structured fault characteristics are transformed into actionable repair solutions. Through the reuse of historical cases and expert knowledge retrieval, intelligent fault response and experience accumulation are achieved. Furthermore, by combining the semantic understanding and generation capabilities of large-scale models, interpretable and traceable handling suggestions are provided for fault diagnosis.

[0209] Optionally, multimodal feature fusion technology can be introduced during RAG analysis to improve the accuracy of fault repair solution generation. Specifically, before converting the current fault features into a fingerprint vector for knowledge base retrieval, the electronic device extracts sensor data (including LiDAR point clouds, camera images, and millimeter-wave radar data) associated with the fault from causal information chains and fault event information as auxiliary input. The electronic device maps text log features and sensor data features to the same semantic space through a cross-modal feature extraction model to generate a fused feature vector. The electronic device concatenates or weights this fused feature vector with the defect fingerprint vector as a joint input vector for knowledge base retrieval, and retrieves historical fault cases and repair solutions matching the current fault in the knowledge base.

[0210] Optionally, when performing knowledge base searches, the electronic device dynamically adjusts the search weights based on the urgency of the current fault and the matching degree between historical cases. Specifically, the electronic device determines the problem classification label and urgency level of the current fault based on the description information and fault category identifier in the first fault information. Then, it determines the weight allocation strategy for each search dimension based on the problem classification label and urgency level. Combining semantic similarity, urgency level weight, and case resolution efficiency score, it calculates and sorts the comprehensive matching degree of each historical case, selecting a preset number of cases with the highest comprehensive matching degree as the search results. Through the above method, high-priority safety-related faults can quickly obtain safety-related repair solutions, while low-priority performance-related faults prioritize the reuse of performance optimization solutions, avoiding the insufficient relevance caused by traditional RAG searches and improving the timeliness and targeting of repair solutions.

[0211] S906, Fault report generation.

[0212] In this embodiment, by automating fault diagnosis and combining the semantic understanding and generation capabilities of a large model to locate the root cause of problems, manpower is greatly reduced and the efficiency of problem closure is improved. The large model, through learning from a large number of fault handling cases and its built-in knowledge base, can achieve expert-level problem handling capabilities, quickly providing the root cause to developers. Moreover, it has extremely high scalability. Therefore, this method uses artificial intelligence technology to solve the automatic analysis of autonomous driving fault logs, fault location, and problem ticket creation, imbuing AI with expert experience and knowledge bases to quickly and automatically analyze and locate problems from massive logs, improving efficiency and freeing up manpower.

[0213] Figure 10 This is a schematic diagram of a vehicle fault determination device provided in an embodiment of this application. Please refer to... Figure 10 The vehicle fault determination device 1000 includes: an acquisition module 1001, a determination module 1002, an identification module 1003, and a processing module 1004, wherein:

[0214] The acquisition module 1001 is used to acquire first fault information of the vehicle during driving, the first fault information including description information and time of occurrence;

[0215] The determination module 1002 is used to perform spatiotemporal extraction on the first fault information based on the description information and the time period of occurrence to obtain multiple second fault information, and determine the corresponding fault event information based on the multiple second fault information;

[0216] The identification module 1003 is used to perform hierarchical fault identification on fault event information according to a preset rule base, and determine the causal information chain corresponding to each fault event information.

[0217] The processing module 1004 is used to determine multiple target fault root causes based on each fault event information and the corresponding causal information chain, and to generate a vehicle fault report based on the multiple target fault root causes.

[0218] In one possible implementation, the determining module 1002 is specifically used for:

[0219] Based on the description information, spatial extraction is performed on the first fault information to obtain the third fault information;

[0220] Based on the time period of occurrence, the third fault information is extracted in time sequence to obtain multiple second fault information.

[0221] In one possible implementation, the determining module 1002 is specifically used for:

[0222] Determine whether each of the second fault messages contains a hardware fault;

[0223] When a hardware fault is detected in the second fault information, the second fault information is processed according to timing to obtain fault event information.

[0224] In one possible implementation, the determining module 1002 is specifically used for:

[0225] Based on a preset time window, the second fault information is filtered to obtain multiple adjacent fault events;

[0226] Multiple adjacent fault events are sorted and reorganized to obtain fault event information.

[0227] In one possible implementation, the identification module 1003 is specifically used for:

[0228] For any fault event information, the rule base is traversed layer by layer to see if there is a corresponding fault event information. When it is determined that there is no corresponding fault event information, the current fault level is determined as the root cause level.

[0229] Generate a causal information chain based on the root cause hierarchy.

[0230] In one possible implementation, the processing module 1004 is specifically used for:

[0231] Based on the pre-trained language model, information on each fault event, and the corresponding causal information chain, multiple candidate root causes of the fault are identified.

[0232] Multiple target root causes are identified from a pool of candidate root causes.

[0233] In one possible implementation, the processing module 1004 is specifically used for:

[0234] Determine the event weight, hierarchy weight, scope weight, and repair weight for each candidate root cause of failure;

[0235] Based on the event weight, hierarchy weight, scope weight, and repair weight, calculate the fault score for each candidate root cause, and obtain multiple target root causes based on the fault scores.

[0236] In one possible implementation, the processing module 1004 is specifically used for:

[0237] Search the preset knowledge base to obtain historical failure cases that match the root cause of the target failure.

[0238] A fault report is generated based on a pre-trained language model, historical fault cases, and the target fault root cause.

[0239] The vehicle fault determination device provided in this application embodiment can execute the technical solution shown in the above method embodiment. Its implementation principle and beneficial effects are similar, and will not be described again here.

[0240] Figure 11 This is a schematic diagram of the vehicle fault determination device provided in an embodiment of this application. Figure 11 As shown, the vehicle fault determination device 1100 may include: transceiver 1101, processor 1102, and memory 1103.

[0241] Processor 1102 executes computer execution instructions stored in memory, causing processor 1102 to perform the scheme in the above embodiments. Processor 1102 may be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; it may also be a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components.

[0242] The memory 1103 is connected to the processor 1102 via the system bus and completes communication between them. The memory 1103 is used to store computer program instructions.

[0243] Transceiver 1101 can be used to obtain the task to be run and the configuration information of the task to be run.

[0244] The system bus can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. The system bus can be divided into address bus, data bus, control bus, etc. For ease of representation, only one thick line is used in the diagram, but this does not indicate that there is only one bus or one type of bus. Transceivers are used to enable communication between database access devices and other computers (e.g., clients, read-write libraries, and read-only libraries). Memory may include random access memory (RAM) and may also include non-volatile memory.

[0245] This application also provides a chip for executing instructions, which is used to execute the technical solution of the vehicle fault determination method in the above embodiments.

[0246] This application also provides a computer-readable storage medium storing computer instructions that, when executed on a computer, cause the computer to perform the technical solution of the vehicle fault determination method described in the above embodiments.

[0247] This application also provides a computer program product, which includes a computer program stored in a computer-readable storage medium. At least one processor can read the computer program from the computer-readable storage medium. When the at least one processor executes the computer program, it can implement the technical solution of the vehicle fault determination method in the above embodiments.

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

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

[0250] Furthermore, the functional modules in the various embodiments of this application can be integrated into one processing unit, or each module can exist physically separately, or two or more modules can be integrated into one unit. The unit composed of the above modules can be implemented in hardware or in the form of hardware plus software functional units.

[0251] The integrated modules described above, implemented as software functional modules, can be stored in a computer-readable storage medium. These software functional modules, stored in a storage medium, include several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) or processor to execute some steps of the methods of the various embodiments of this application.

[0252] It should be understood that the aforementioned processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. A general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in this invention can be directly manifested as execution by a hardware processor, or execution by a combination of hardware and software modules within the processor.

[0253] The memory may include high-speed RAM, and may also include non-volatile storage (NVM), such as at least one disk storage device, and may also be a USB flash drive, external hard drive, read-only memory, disk or optical disc, etc.

[0254] The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, the buses shown in the accompanying drawings are not limited to a single bus or a single type of bus.

[0255] The aforementioned storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The storage medium can be any available medium that can be accessed by a general-purpose or special-purpose computer.

[0256] An exemplary storage medium is coupled to a processor, enabling the processor to read information from and write information to the storage medium. Alternatively, the storage medium can be an integral part of the processor. The processor and storage medium can reside in an Application Specific Integrated Circuit (ASIC). Alternatively, the processor and storage medium can exist as discrete components in an electronic control unit or main control device.

[0257] Those skilled in the art will understand that all or part of the steps of the above-described method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When executed, the program performs the steps of the above-described method embodiments; and the aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disks, or optical disks.

[0258] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features therein. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

Claims

1. A method for determining vehicle faults, characterized in that, The method includes: Acquire first fault information of the vehicle during driving, the first fault information including description information and time of occurrence; Based on the description information and the occurrence time period, the first fault information is spatiotemporally extracted to obtain multiple second fault information, and the corresponding fault event information is determined based on the multiple second fault information; Based on a preset rule base, hierarchical fault identification is performed on the fault event information to determine the causal information chain corresponding to each fault event information. Based on the fault event information and the corresponding causal information chain, multiple target fault root causes are determined, and a fault report for the vehicle is generated based on the multiple target fault root causes.

2. The method according to claim 1, characterized in that, Based on the description information and the time period of occurrence, spatiotemporal extraction is performed on the first fault information to obtain multiple second fault information items, including: Based on the description information, spatial extraction is performed on the first fault information to obtain the third fault information; Based on the time period of occurrence, the third fault information is extracted in time sequence to obtain the plurality of second fault information.

3. The method according to claim 1, characterized in that, Based on the plurality of second fault information, the corresponding fault event information is determined, including: Determine whether each of the second fault messages contains a hardware fault; When a hardware fault exists in the second fault information, the second fault information is processed according to timing to obtain the fault event information.

4. The method according to any one of claims 1-3, characterized in that, The second fault information is processed according to timing to obtain the fault event information, including: Based on a preset time window, the second fault information is filtered to obtain multiple adjacent fault events; The multiple adjacent fault events are sorted and reorganized to obtain the fault event information.

5. The method according to claim 1, characterized in that, Based on a preset rule base, hierarchical fault identification is performed on the fault event information to determine the causal information chain corresponding to each fault event information, including: For any fault event information, the rule base is traversed layer by layer to see if there is a corresponding fault event information. When it is determined that there is no corresponding fault event information, the current fault level is determined as the root cause level. The causal information chain is generated based on the root cause hierarchy.

6. The method according to claim 1, characterized in that, Based on the information of each fault event and the corresponding causal information chain, multiple target fault root causes are determined, including: Based on the pre-trained language model, the information of each fault event, and the corresponding causal information chain, multiple candidate root causes of faults are determined. Among the plurality of candidate root causes of failure, the plurality of target root causes of failure are determined.

7. The method according to claim 6, characterized in that, Determining the target root cause from the plurality of candidate root causes includes: Determine the event weight, hierarchy weight, scope weight, and repair weight for each candidate root cause of failure; Based on the event weight, the hierarchy weight, the range weight, and the repair weight, calculate the fault score for each candidate root cause, and obtain the multiple target root causes based on the fault scores.

8. The method according to claim 1, characterized in that, Based on the multiple target root causes of failure, a fault report for the vehicle is generated, including: Search the preset knowledge base to obtain historical failure cases that match the target failure root cause; The fault report is generated based on the pre-trained language model, the historical fault cases, and the target fault root cause.

9. A device for determining vehicle faults, characterized in that, include: A processor, and a memory communicatively connected to the processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory to implement the method as described in any one of claims 1-8.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the method as described in any one of claims 1-8.

Images