Defect processing method for application, vehicle, electronic device, and storage medium

Abstract

The embodiment of the specification provides a defect processing method of an application, and relates to the technical field of vehicles. The method comprises the following steps: obtaining defect information associated with a target application; then performing semantic understanding on the defect information to determine a preset fault type corresponding to the defect information, converting unstructured natural language description into structured fault classification, and providing accurate instructions for subsequent processing; on this basis, configuring a log path according to the preset fault type and obtaining associated running logs, realizing on-demand and accurate acquisition of logs, and replacing blind screening of artificial in full logs; then, determining standard process information associated with the running logs and comparing the standard process information with the running logs, automatically aligning an actual execution path with an expected standard process to identify deviations; and then obtaining processing operations through analysis of the comparison information, outputting root cause conclusions or processing suggestions, and improving the accuracy and efficiency of defect processing.

Description

Technical Field

[0001] This specification relates to the field of vehicle technology, specifically to intelligent cockpit technology within the field of vehicle technology, and more specifically to an application of defect handling methods, vehicles, electronic devices, and storage media. Background Technology

[0002] In the field of intelligent cockpit software function development and testing technology, facing increasingly complex system functions and massive runtime logs, how to quickly and accurately locate and reproduce software defects is a key common requirement for improving development and testing efficiency and ensuring product quality.

[0003] To achieve the above goals, a manual defect analysis and log review process is typically employed. After testers submit issues on the defect management platform, developers need to manually extract information such as the issue description and reproduction time, and manually download the full logs from the server or vehicle-mounted system. Developers then rely on their personal experience to handle the defect. This process is time-consuming and labor-intensive, and errors are prone to occur during the processing of massive amounts of data, affecting the accuracy and efficiency of defect handling. Summary of the Invention

[0004] This specification provides an example of a defect-handling vehicle, electronic device, and storage medium that improves the accuracy and efficiency of defect handling.

[0005] To achieve the above technical objectives, the embodiments of this specification provide the following technical solutions: Firstly, one embodiment of this specification provides a defect handling method for an application, comprising: Obtain defect information associated with the target application; Perform semantic understanding on the defect information to determine the preset fault type corresponding to the defect information; Configure the log path according to the preset fault type, so as to obtain the running log associated with the defect information based on the log path; Determine the standard process information associated with the operation log, and compare the standard process information with the operation log to obtain comparison information; By analyzing the comparison information, processing operations can be obtained for the defect information.

[0006] This implementation first acquires defect information associated with the target application, automatically retrieving orders from the defect management platform and eliminating repetitive manual login and copying operations. Next, semantic understanding is performed on the defect information to determine its corresponding preset fault type, transforming unstructured natural language descriptions into structured fault classifications, providing precise instructions for subsequent processing. Based on this, log paths are configured according to the preset fault types, and associated runtime logs are retrieved, enabling on-demand and precise log acquisition, replacing manual blind sifting through the entire log volume. Subsequently, standard process information associated with the runtime logs is determined and compared with the runtime logs, automatically aligning the actual execution path with the expected standard process to identify deviations. Finally, processing operations are derived through comparative information analysis, outputting root cause conclusions or processing suggestions. This approach avoids the problems of tedious manual operations, reliance on experience, and low efficiency, improving the accuracy and efficiency of defect handling.

[0007] Optionally, in one possible implementation, the step of performing semantic understanding on the defect information to determine the preset fault type corresponding to the defect information includes: The natural language model associated with the target application is invoked; the natural language model is fine-tuned using cockpit domain data. Semantic understanding is performed based on the defect information in the natural language model to determine the semantic information corresponding to the defect information; Based on the semantic information, the preset fault type corresponding to the defect information is determined.

[0008] In this implementation, a natural language model fine-tuned using cockpit-specific data is invoked. This model, trained on domain-specific corpora, accurately understands cockpit-specific terminology and expressions. Then, based on this model, semantic understanding of defect information is performed to determine its corresponding semantic information, avoiding ambiguity or misjudgment caused by the lack of domain knowledge in general models. Finally, a preset fault type is determined based on the semantic information. By introducing a cockpit-specific fine-tuned natural language model, the accuracy and robustness of fault classification are significantly improved, enabling subsequent log screening and comparative analysis to be conducted under correct classification guidance, thus ensuring the reliability of the entire automated analysis process from the source.

[0009] Optionally, in one possible implementation, determining the preset fault type corresponding to the defect information based on the semantic information includes: Based on the semantic information, determine the fault action information corresponding to the defect information; Identify the object entities associated with the cockpit domain contained in the semantic information; By combining the fault action information and the object entity, the preset fault type corresponding to the defect information is determined.

[0010] In this implementation, fault action information corresponding to defect information is determined based on semantic information. Simultaneously, the object entities associated with the cockpit domain contained in the semantic information are identified, achieving a hierarchical information recognition process. Then, the fault action information is combined and matched with the object entities to accurately determine the preset fault type. This fine-grained classification method, which decouples and recombines actions and entities, can more accurately locate the specific functional point and anomaly type where the fault occurs, providing more precise keywords and path configurations for subsequent log filtering, thereby improving the accuracy of the analysis.

[0011] Optionally, in one possible implementation, configuring a log path according to the preset fault type to obtain the runtime log associated with the defect information based on the log path includes: Determine the time window and functional module for indicating the defect information; Configure the log path according to the functional modules and the preset fault types; Obtain the set of keywords indicating the preset fault type; The logs associated with the keyword set are filtered according to the time window and the log path to obtain the running logs associated with the defect information.

[0012] In this implementation, the time window and functional modules for defect information indication are determined, clarifying the temporal and spatial boundaries of log filtering. Secondly, log paths are configured according to functional modules and preset fault types, enabling precise location of log sources and avoiding the inefficient operation of traversing all log directories. Then, a set of keywords indicating preset fault types is obtained, providing precise matching rules for log content filtering. Finally, logs associated with the keyword set are filtered according to the time window and log path to obtain the runtime logs associated with the defect information. Through this multi-dimensional combined filtering, precise filtering of massive amounts of logs is achieved, significantly reducing the size of effective logs and providing high-quality data input for subsequent comparative analysis, while reducing interference from invalid data.

[0013] Optionally, in one possible implementation, filtering the logs associated with the keyword set according to the time window and the log path to obtain the runtime logs associated with the defect information includes: Obtain the reference window parameters of the preset fault type indication; The time window is adjusted according to the reference window parameters; Identify the target information sources that are compatible with the adjusted time window; According to the adjusted time window, the logs of the target information source are filtered by referring to the keyword set through the log path to obtain the running logs associated with the defect information.

[0014] In this implementation, a reference window parameter indicating the preset fault type is obtained. Different types of faults may correspond to different suitable analysis time ranges. Then, the original time window is adjusted according to this reference window parameter to achieve adaptive optimization of the time window, avoiding the omission of key logs due to an overly narrow window or the introduction of excessive noise due to an overly wide window. Next, the target information source adapted to the adjusted time window is determined to ensure the accuracy of the log source. Finally, filtering is performed according to the adjusted time window. By introducing an adaptive time window adjustment mechanism based on fault type, log segments strongly related to faults can be captured more intelligently, improving the recall rate of key logs and further reducing interference from irrelevant logs.

[0015] Optionally, in one possible implementation, determining the standard process information associated with the runtime log and comparing the standard process information with the runtime log to obtain comparison information includes: Determine the standard process information associated with the operation log, and determine the process nodes included in the standard process information; Based on the timestamps of the running logs, information is aligned according to the process nodes to obtain a comparison sequence; Determine the status information and execution information indicated by the alignment sequence; The comparison information between the standard process information and the operation log is based on the status information and the execution information.

[0016] In this implementation, by identifying the standard process information associated with the runtime log and the process nodes it contains, the normal code logic is made explicit into a sequence of process nodes that can be operated by the machine. Then, based on the timestamps of the runtime log, information is aligned according to the process nodes to obtain a comparison sequence, achieving a precise correspondence between the actual execution path and the expected execution path on the timeline. Next, the status information and execution information indicated by the comparison sequence are determined, such as the execution status and actual execution actions of each node. Based on this information, comparison information between the standard process information and the runtime log is generated. Through this comparison method of time-series alignment and node status extraction, the specific node where the anomaly occurred, the missing steps, and the abnormal state transitions can be accurately located, providing clear evidence for root cause analysis.

[0017] Optionally, in one possible implementation, the step of analyzing the comparison information to obtain processing operations for the defect information includes: By analyzing the comparison information, abnormal nodes can be identified. Identify the differential log fragment associated with the abnormal node; Based on the root cause classification indicated by the difference log fragment, determine the processing operation for the defect information.

[0018] In this implementation, information is analyzed by comparison to identify abnormal nodes that deviate from the standard process, and the description of the differences is refined. Then, the difference log fragments associated with the abnormal nodes are determined, and key evidence supporting the anomaly judgment is extracted. Finally, based on the root cause classification indicated by the difference log fragments, the processing operations for the defect information are determined. Through the above progressive analysis, not only is the problem output, but the cause of the problem is also provided, offering developers directly usable decision support and significantly improving defect repair efficiency.

[0019] Secondly, one embodiment of this specification provides an application defect processing apparatus, comprising: The acquisition unit is used to acquire defect information associated with the target application; The processing unit is used to perform semantic understanding on the defect information in order to determine the preset fault type corresponding to the defect information; The processing unit is further configured to configure a log path according to the preset fault type, so as to obtain the running log associated with the defect information based on the log path; The processing unit is further configured to determine the standard process information associated with the operation log, and compare the standard process information with the operation log to obtain comparison information; The processing unit is further configured to analyze the comparison information to obtain processing operations for the defect information.

[0020] Thirdly, one embodiment of this specification also provides an application defect handling system, including a sensor and a vehicle controller, wherein the sensor is used to collect vehicle-related data; and the vehicle controller is used to execute the application defect handling method as described in the first aspect or any possible implementation thereof.

[0021] Fourthly, one embodiment of this specification also provides a vehicle, the vehicle comprising: a memory for storing executable program code; and a processor for calling and running the executable program code from the memory, causing the vehicle to perform the defect handling method applied in the first aspect or any possible implementation of the first aspect.

[0022] Fifthly, one embodiment of this specification also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the defect handling method of the application described above.

[0023] Sixthly, embodiments of this specification provide a computer program product or computer program, the computer program product including a computer program that can be stored in a computer-readable storage medium or in the cloud; the processor of the computer device reads the computer program, and when the processor executes the computer program, it implements the steps of the above-described defect handling method for the application.

[0024] As can be seen from the above technical solution, the defect handling method for the application provided in this specification first obtains the defect information associated with the target application, realizing automatic order retrieval from the defect management platform and eliminating repetitive operations such as manual login and copying; then, it performs semantic understanding on the defect information to determine its corresponding preset fault type, transforming unstructured natural language descriptions into structured fault classifications, providing precise instructions for subsequent processing; based on this, it configures log paths according to preset fault types and obtains associated operation logs, realizing on-demand and precise log acquisition, replacing manual blind screening of the entire log; subsequently, it determines the standard process information associated with the operation logs and compares it with the operation logs, automatically aligning the actual execution path with the expected standard process, thereby identifying deviations; then, it obtains processing operations through comparative analysis of the information, outputting root cause conclusions or processing suggestions; this avoids the problems of cumbersome manual operations, reliance on experience, and low efficiency, improving the accuracy and efficiency of defect handling. Attached Figure Description

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

[0026] Figure 1 Network architecture diagram for the application's defect handling system.

[0027] Figure 2 This is a flowchart illustrating a defect handling method for an application provided as one embodiment of this specification.

[0028] Figure 3 This is a schematic diagram illustrating a scenario of a defect handling method for an application provided in one embodiment of this specification.

[0029] Figure 4 A schematic diagram of the functional modules of a defect handling device for an application provided in one embodiment of this specification.

[0030] Figure 5 This is a structural schematic diagram of a vehicle provided for one embodiment of this specification. Detailed Implementation

[0031] Unless otherwise defined, the technical or scientific terms used in the embodiments of this specification shall have the ordinary meaning understood by one of ordinary skill in the art to which this specification pertains. The terms "first," "second," and similar terms used in the embodiments of this specification do not indicate any order, quantity, or importance, but are merely used to avoid confusion of constituent elements.

[0032] Unless the context otherwise requires, throughout this specification, "a plurality of" means "at least two," and "including" is interpreted as open-ended or encompassing, that is, "including, but not limited to." In the description of this specification, terms such as "one embodiment," "some embodiments," "exemplary embodiment," "example," "specific example," or "some examples" are intended to indicate that a particular feature, structure, material, or characteristic associated with that embodiment or example is included in at least one embodiment or example of this specification. The illustrative representations of the above terms do not necessarily refer to the same embodiment or example.

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

[0034] In the field of intelligent cockpit software function development and testing technology, facing increasingly complex system functions and massive runtime logs, how to quickly and accurately locate and reproduce software defects is a key common requirement for improving development and testing efficiency and ensuring product quality.

[0035] To achieve the above goals, a manual defect analysis and log review process is typically employed. After testers submit issues on the defect management platform, developers need to manually extract information such as the issue description and reproduction time, and manually download the full logs from the server or vehicle-mounted system. Developers then rely on their personal experience to compare the logs with the code logic and normal workflow manuals they remember; and manually determine the cause of the problem and locate the defect. This process is highly repetitive, requiring log downloading, keyword filtering, and time extraction—all mechanically repetitive operations; it relies heavily on experience, meaning log filtering and logic matching depend heavily on the developer's memory and proficiency, making it slow for newcomers to learn and prone to overlooking issues; it is inefficient, as locating a single issue is time-consuming, and multiple issues running concurrently can easily hinder testing and development progress; the information is not standardized, with colloquial problem descriptions and diverse log formats, making manual processing prone to errors; and knowledge cannot be accumulated, as code flow, failure modes, and log characteristics exist only in personal experience and cannot form a reusable knowledge base.

[0036] It is evident that this process is time-consuming and labor-intensive, and errors are easily generated during the processing of massive amounts of data, affecting the accuracy and efficiency of defect handling.

[0037] To address the aforementioned issues, this specification provides a defect handling system for an application, and the defect handling method provided in this specification is applied to the defect handling system for that application. In the development and testing phase of intelligent cockpit functions, this system automates the entire process from order retrieval to conclusion by automatically acquiring defect information, automatically filtering key logs, automatically matching code flow, and outputting the root cause of the problem. This eliminates the need for manual operation, significantly reduces log analysis time, and greatly improves efficiency.

[0038] It should be understood that the defect handling method for applications provided in this application can be applied to systems or programs in terminal devices that include application defect handling functions, such as cockpit management applications in vehicles. Specifically, the application defect handling system can run in environments such as... Figure 1 In the network architecture shown, such as Figure 1 The diagram shown illustrates the network architecture of the application's defect handling system. As can be seen, the system can handle defect requests from multiple information sources. Specifically, it determines logistics requests through interaction with the terminal, triggering the server to perform the corresponding defect handling process. This can be understood as... Figure 1 The document illustrates various terminal devices, which can be computer devices. In real-world scenarios, more or fewer types of terminal devices may participate in the application's defect handling process. The specific number and types depend on the actual scenario and are not limited here. Additionally, Figure 1The example shows one server, but in real-world scenarios, multiple servers can be involved, especially in multidisciplinary output scenarios. The specific number of servers depends on the actual scenario.

[0039] In this embodiment, the server can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN, and big data and artificial intelligence platforms. The terminal can be a smartphone, tablet, laptop, desktop computer, smart speaker, smartwatch, etc., but is not limited to these. The terminal and server can be directly or indirectly connected via wired or wireless communication, and the terminal and server can be connected to form a blockchain network; this application does not impose any restrictions.

[0040] It is understood that the defect handling system of the above-mentioned application can run on the vehicle, for example, as a cockpit management application, or it can run on a server, or it can run on a third-party device to provide defect handling for the application and obtain the defect handling results of the information source application; the specific defect handling system of the application can run in the above-mentioned device as a program, or it can run as a system component in the above-mentioned device, or it can run as a cloud service program. The specific operation mode depends on the actual scenario and is not limited here.

[0041] Specifically, when handling defects within a vehicle using the aforementioned processing system, the system first obtains defect information associated with the target application, enabling automatic order retrieval from the defect management platform and eliminating repetitive manual login and copying operations. Next, semantic understanding of the defect information is performed to determine its corresponding preset fault type, transforming unstructured natural language descriptions into structured fault classifications, providing precise instructions for subsequent processing. Based on this, log paths are configured according to the preset fault type, and associated operational logs are obtained, achieving on-demand and precise log acquisition, replacing manual blind sifting through the entire log volume. Subsequently, standard process information associated with the operational logs is determined and compared with the operational logs, automatically aligning the actual execution path with the expected standard process to identify deviations. Finally, processing operations are derived through comparative information analysis, outputting root cause conclusions or processing suggestions. This avoids the problems of cumbersome manual operations, reliance on experience, and low efficiency, improving the accuracy and efficiency of defect handling.

[0042] Based on the above concept, this specification provides a method for handling application defects. The following description, in conjunction with the accompanying drawings, will provide an exemplary description of the method for handling application defects provided in this specification.

[0043] To be applied Figure 1 Taking the client as an example, this specification provides illustrative examples of some implementation methods for handling defects in the application, such as... Figure 2 As shown, Figure 2 This is a flowchart illustrating a defect handling method for an application provided in one embodiment of this specification; the defect handling method for the application includes: 201. Obtain defect information associated with the target application.

[0044] In this embodiment, the target application refers to a software system or functional module deployed on any terminal device (including but not limited to smart cockpits, smartphones, tablets, industrial control panels, smart home hubs, robot operating systems, etc.). During operation, this application generates defect information (such as crash logs, abnormal events, performance degradation records, etc.) and can output it externally through a defect management platform or local interface. This embodiment uses the handling of application defects in a vehicle's smart cockpit as an example for illustration.

[0045] Correspondingly, defect information refers to the structured or unstructured data set recorded by testers during the verification of intelligent cockpit functions for any abnormal phenomena they discover. It typically includes fields such as problem title, phenomenon description, reproduction time, reproduction steps, relevant functional module, environmental information, and priority. As the input source for the entire automated analysis process, it carries the original context of the problem's occurrence.

[0046] Understandably, defects in smart cockpits typically occur during the operation of complex systems with highly integrated hardware and software, and their causes encompass multiple interactive scenarios. On one hand, defects may stem from abnormal coupling between functional modules, such as resource contention when the voice assistant and navigation system simultaneously access the microphone, leading to unresponsive voice wake-up. On the other hand, unstable hardware signals or depletion of underlying system resources can also trigger problems, such as camera module initialization timeouts in low-temperature environments causing a black screen for the reversing camera. Furthermore, external environmental factors such as electromagnetic interference, network fluctuations, and unconventional user operation sequences can all disrupt the system's preset normal execution path, causing state machine transition errors or interface call timeouts. These defects are presented in the form of log records and phenomenon descriptions. Their occurrence time, functional modules, and environmental information together constitute the core data in the defect information platform, providing the initial basis for subsequent automated analysis.

[0047] Specifically, defect information can originate from a defect information acquisition module, which interfaces with the defect information platform's data interface (API) to automatically retrieve issue titles, descriptions, reproduction times, modules, and severity levels. The defect information platform is a core support system in the software development and testing process for centrally recording, tracking, and managing defects; typical examples include Jira and GitLab Issues. This platform generates a unique identifier for each defect and structurally stores key fields such as issue title, phenomenon description, reproduction steps, occurrence time, module, environmental information, priority, and processing status, serving as the data hub for the entire defect handling process. In this technical solution, the defect information platform outputs defect data in a standardized format to the automated analysis system through an open REST API interface. This allows the system to retrieve the latest defect reports in real-time or periodically and populate the corresponding defect records with the root cause conclusions and handling suggestions derived from the final analysis.

[0048] In one possible scenario, defect information can be obtained automatically through AI to acquire Jira issue information. That is, the system can retrieve defect reports through API on a regular / real-time basis and extract: problem description, reproduction time, module, and environment information.

[0049] 202. Perform semantic understanding on the defect information to determine the preset fault type corresponding to the defect information.

[0050] In this embodiment, the preset fault type refers to a set of standardized fault classification labels predefined based on cockpit domain knowledge. These labels are used to map the problem phenomena described in natural language to structured anomaly categories, such as black screen, no sound, Bluetooth connection failure, touch unresponsiveness, navigation lag, application crash, etc., serving as a key bridge connecting semantic understanding with subsequent log filtering and process comparison.

[0051] Therefore, to identify preset fault types, semantic understanding based on Natural Language Processing (NLP) can be used. NLP is a branch of artificial intelligence that focuses on enabling computers to interact with human natural language. Its core goal is to enable machines to understand, parse, and generate semantic information in human language. In the scenario of intelligent cockpit defect analysis, NLP technology is used to process unstructured text in defect information. Through operations such as word segmentation, entity recognition, and intent classification, fault actions ("no response") and object entities ("voice assistant") are extracted from colloquial problem descriptions (such as "the voice assistant hasn't responded after being called for a long time"), and mapped to standardized preset fault types. This transforms human-readable natural language into machine-executable classification instructions. Specific NLP methods can include pre-trained language models (such as BERT), sequence labeling and classification models (such as BiLSTM-CRF), and generative large language models (such as Qwen).

[0052] In one possible scenario, the semantic understanding process can utilize a natural language model fine-tuned with cockpit-specific data. This fine-tuning process uses problem descriptions from historical cockpit defect reports as training data, enabling the model to learn cockpit-specific terminology, expressions, and classification boundaries, thereby improving classification accuracy.

[0053] Specifically, for fine-tuning NLP recognition, the first step is to call the natural language model associated with the vehicle, which is then fine-tuned using cockpit domain data. Next, semantic understanding is performed based on the defect information obtained from the natural language model to determine the semantic information corresponding to the defect information. Finally, based on the semantic information, the preset fault type corresponding to the defect information is determined.

[0054] For example, the system calls the fine-tuned BERT model to handle the problem description "stuttering during Bluetooth music playback". The general model might classify it as "performance problem", but the fine-tuned model, because its training data contains a large number of Bluetooth A2DP-related defect samples, can accurately classify it as "abnormal Bluetooth audio transmission", providing accurate fault type labels for subsequent log filtering.

[0055] As can be seen, in this embodiment, by invoking a natural language model fine-tuned from cockpit domain data—which has been trained on domain-specific corpora—it can accurately understand cockpit-specific terms and expressions such as "black screen," "Bluetooth disconnection," and "voice wake-up unresponsiveness." Then, based on this model, semantic understanding of the defect information is performed to determine its corresponding semantic information, avoiding ambiguity or misjudgment caused by the lack of domain knowledge in general models. Furthermore, a preset fault type is determined based on the semantic information. By introducing a cockpit-domain fine-tuned natural language model, this method significantly improves the accuracy and robustness of fault classification, enabling subsequent log screening and comparative analysis to be conducted under correct classification guidance, thus ensuring the reliability of the entire automated analysis process from the source.

[0056] Furthermore, the semantic understanding process can be further refined based on category granularity. That is, by extracting "fault actions" (such as connection failure, no response) and "object entities" (such as Bluetooth, navigation) from the defect description, the two can be combined to determine the fine-grained preset fault type, thereby achieving a deeper understanding from coarse-grained classification to fine-grained localization.

[0057] Specifically, to determine the preset fault type, we can first determine the fault action information corresponding to the defect information based on the semantic information; then determine the object entity associated with the cockpit domain included in the semantic information; and combine the fault action information and the object entity to determine the preset fault type corresponding to the defect information.

[0058] For example, the system handles the problem description "delay in camera image display when reversing". The semantic understanding module extracts the fault action as "display delay", and the object entities as "camera" and "reversing scene". After combination, it determines the preset fault type as "reversing image display delay", rather than the generalized "interface abnormality" or "performance abnormality", thus providing more accurate functional module positioning for subsequent log filtering.

[0059] In this embodiment, the fault action information corresponding to the defect information is determined based on semantic information, such as identifying specific actions like "connection failure," "no response," and "black screen." Simultaneously, the object entities associated with the cockpit domain contained in the semantic information are determined, such as identifying specific functional modules or components like "Bluetooth," "navigation," and "voice assistant." Then, the "fault action information" and "object entities" are combined and matched to accurately determine the preset fault type (such as "Bluetooth connection failure" rather than the generalized "communication anomaly"). Through this fine-grained classification method of decoupling and recombining actions and entities, this method can more accurately locate the specific functional point and anomaly type where the fault occurs, providing more precise keywords and path configurations for subsequent log filtering, thereby improving the accuracy of the analysis.

[0060] Understandably, the aforementioned semantic understanding process can be applied to the AI ​​semantic understanding and classification module. This module is used to perform NLP parsing on the problem description and classify it into known fault modes. Specifically, AI performs intent recognition and fault classification on the natural language description and maps it to preset fault types (such as: black screen, no sound, Bluetooth connection failure, touch unresponsiveness, etc.).

[0061] 203. Configure the log path according to the preset fault type to obtain the operation log associated with the defect information based on the log path.

[0062] In this embodiment, the log path refers to the directory address or access interface where various log files in the vehicle system are stored. It is divided according to different functional modules, subsystems, or log types (such as system logs, application logs, kernel logs, and network logs) to guide automated tools in accurately locating and obtaining log sources relevant to the current fault analysis, avoiding the inefficient operation of traversing the entire log directory. Correspondingly, the runtime log (log) refers to the event log file automatically recorded by the intelligent cockpit system during operation. It contains the execution status of each functional module, function call sequence, error code output, exception stack, communication messages, and timestamp information. It is the original data carrier reflecting the actual execution path of the system and the core evidence source for root cause analysis.

[0063] In one possible scenario, the process of obtaining operation logs can be achieved by combining the time window and functional module in the defect information with the log path and keyword set configured by the preset fault type, so as to narrow down the scope of log retrieval from the source.

[0064] Specifically, the time window and functional module for indicating defect information can be determined first; then the log path can be configured according to the functional module and the preset fault type; and the keyword set for indicating the preset fault type can be obtained; then the logs associated with the keyword set can be filtered according to the time window and the log path to obtain the running logs associated with the defect information.

[0065] For example, the system handles defects categorized as "Bluetooth connection failure," with defect information including the reproduction time 2025-03-20 14:23:15 and the module identifier "bluetooth." The system's log paths are configured as / data / logs / bluetooth / and / data / logs / system / . The system retrieves the keyword set ["connect", "failed", "timeout", "A2DP"] and filters it according to the time window 14:22:00 to 14:25:00. Finally, it outputs log segments containing the aforementioned keywords within this time period, excluding a large number of irrelevant WiFi, GPS, and other logs.

[0066] As can be seen, this embodiment clarifies the time and spatial boundaries of log filtering by determining the time window and functional modules for defect information indication. Secondly, by configuring log paths according to functional modules and preset fault types, it achieves precise location of log sources, avoiding the inefficient operation of traversing all log directories. Then, it obtains a set of keywords indicating preset fault types, providing precise matching rules for log content filtering. Finally, it filters logs associated with the keyword set according to the time window and log path, obtaining the runtime logs associated with the defect information. Through multi-dimensional combined filtering of "time window + functional module + log path + keywords," this method achieves precise filtering of massive logs, significantly reducing the size of effective logs, providing high-quality data input for subsequent comparative analysis, and reducing interference from invalid data.

[0067] In addition, an adaptive time window adjustment mechanism can be introduced during the log filtering process. The original time window can be expanded or shrunk according to the reference window parameters corresponding to the preset fault type to ensure that the complete log sequence related to the fault type is captured and to avoid the omission of key logs or the introduction of noise due to improper window settings.

[0068] Specifically, for the process of obtaining operation logs, the reference window parameters for pre-setting fault type indication can be obtained first; then the time window can be adjusted according to the reference window parameters; and the target information source adapted to the adjusted time window can be determined; then, according to the adjusted time window, the log reference keyword set of the target information source can be filtered through the log path to obtain the operation log associated with the defect information.

[0069] For example, when the system handles a defect categorized as "application startup crash," the reference window parameters for this defect type are the first 30 seconds and the last 10 seconds. The original time window in the defect information is 10:30:00 to 10:30:05. Based on the reference window, the system adjusts the window to 10:29:30 to 10:30:15, thereby capturing the system resource status log for the 30 seconds before application startup and the exception stack log for the 10 seconds after the crash, providing a complete context for analyzing the root cause of the crash.

[0070] As can be seen, this embodiment obtains reference window parameters indicating preset fault types. Different types of faults may correspond to different adaptive analysis time ranges (for example, "instantaneous black screen" may require a second-level window, while "periodic lag" may require a minute-level window). Then, the original time window is adjusted according to the reference window parameters to achieve adaptive optimization of the time window, avoiding the omission of key logs due to an overly narrow window or the introduction of excessive noise due to an overly wide window. Next, the target information source adapted to the adjusted time window is determined to ensure the accuracy of the log source. Finally, filtering is performed according to the adjusted time window. By introducing an adaptive time window adjustment mechanism based on fault type, this method can more intelligently capture log fragments strongly related to faults, improve the recall rate of key logs, and further reduce the interference of irrelevant logs.

[0071] Understandably, the process of obtaining the aforementioned operational logs can be achieved through an automatic log acquisition and filtering module. This module is used to automatically download and filter key logs based on time windows, fault types, and module paths. In other words, AI automatically acquires key logs based on fault types, matches log paths, keyword sets, and time windows according to fault types, and automatically downloads and filters them from the log server / vehicle infotainment system, retaining only valid log fragments.

[0072] 204. Determine the standard process information associated with the operation log, and compare the standard process information with the operation log to obtain comparison information.

[0073] In this embodiment, standard process information refers to the knowledge base content formed by structurally describing the normal execution logic of each functional module of the intelligent cockpit. It is usually stored in the form of state machine model, timing call chain, standard log sequence or process node diagram, etc., and serves as a benchmark for comparison and analysis to measure whether the actual operation log is consistent with the expected execution path.

[0074] By configuring standard process information, a reference comparison is provided for defect identification. The comparison information refers to the structured output results generated after aligning, matching and detecting differences between the actual operation log and the standard process information. It includes abnormal node identifiers, missing step lists, timeout records, status jump anomalies, error code matching, and timing deviations, providing direct evidence support for root cause analysis.

[0075] In one possible scenario, the comparison process involves breaking down the standard process information into a sequence of process nodes, aligning the actual execution path with each process node based on the timestamps of the runtime logs, extracting the status and execution information corresponding to each node, and generating structured comparison information.

[0076] Specifically, the standard process information associated with the running log can be determined first, and the process nodes included in the standard process information can be determined. Then, based on the timestamp of the running log, the information is aligned according to the process nodes to obtain a comparison sequence. The status information and execution information indicated by the comparison sequence are then determined. Finally, the comparison information between the standard process information and the running log is determined based on the status information and execution information.

[0077] For example, the standard workflow for system navigation startup is: application startup - map loading - route calculation - navigation start. The runtime log timestamps show: 10:00:01 application startup completed, 10:00:05 map loading completed, 10:00:30 route calculation initiated, 10:00:45 route calculation returned timeout error code -1001. After aligning the timestamps, the system marks node 3 "route calculation" as an abnormal node, with a status of "timeout" and an execution information of "returned error code -1001".

[0078] As can be seen, this embodiment makes the implicit "normal code logic" explicit into a sequence of process nodes that can be operated by the machine by determining the standard process information associated with the runtime log and the process nodes it contains. Then, based on the timestamps of the runtime log, the information is aligned according to the process nodes to obtain a comparison sequence, achieving a precise correspondence between the actual execution path and the expected execution path on the timeline. Next, the status information and execution information indicated by the comparison sequence are determined, such as the execution status (success / failure / timeout) and actual execution actions of each node. Then, comparison information between the standard process information and the runtime log is generated based on this information. Through this comparison method of time sequence alignment and node status extraction, this method can accurately locate the specific node where the anomaly occurred, the missing steps, and the abnormal state transitions, providing clear evidence for root cause analysis.

[0079] The construction of standard process information is the configuration process of the work manual / process knowledge base, which stores the normal code flow, state machine, call chain, and standard log sequence of each function in the cockpit. This knowledge base can be configured in the AI ​​logic comparison and root cause analysis module, which is used to compare the actual logs with the standard process to locate missing / abnormal / error nodes.

[0080] Therefore, the standard comparison process can involve AI loading and matching the standard work manual (normal code flow), retrieving the standard execution flow, state transitions, log sequence, and interface call order of the corresponding function from the knowledge base as a benchmark. Then, the AI ​​performs a comparative analysis of the execution logs and the standard flow, that is, comparing the actual log sequence with the standard flow to identify: missing steps, timeouts, abnormal returns, error codes, status freezes, and circular calls, etc.

[0081] 205. Analyze the information by comparison to obtain the processing operations for the defect information.

[0082] In this embodiment, the analysis process may involve locating abnormal nodes by comparing information, extracting the differential log fragments associated with the node, classifying the root causes based on information such as error codes and exception stacks in the differential logs, and finally mapping them to corresponding processing operation suggestions.

[0083] Specifically, the process involves first analyzing the comparison information to identify anomalous nodes; then determining the differential log segments associated with these anomalous nodes; and finally, based on the root cause classification indicated by the differential log segments, determining the appropriate processing actions for the defect information.

[0084] For example, the system locates the abnormal node "Voice Wake-up - Intent Parsing" from the comparison information and extracts the associated difference log fragments. Based on the timeout and 5000ms information in the logs, the root cause is classified as "Service Response Timeout," and the mapped processing action is "It is recommended to check the response latency of the intent parsing service and investigate whether there are thread blocking or resource contention issues." This processing action is directly updated in the Jira defect ticket for developers' reference.

[0085] As can be seen, this embodiment analyzes and compares information to identify abnormal nodes that deviate from the standard process, refining the problem location from the vague "functional anomaly" to the specific "execution step." Then, it identifies the associated difference log segment and extracts key evidence supporting the anomaly judgment. Furthermore, based on the root cause classification indicated by the difference log segment (such as "timeout anomaly," "parameter error," "insufficient resources," etc.), it determines the appropriate handling actions for the defect information (such as "suggest adding a timeout retry mechanism," "check configuration parameters," "investigate memory leaks," etc.). Through this progressive analysis, this method not only outputs "where the problem occurred," but also "what the possible causes are" and "suggested handling methods," providing developers with directly usable decision support and significantly improving defect repair efficiency.

[0086] Understandably, the above analysis process can be configured in the results output module, which is used to automatically generate analysis reports, including problem classification, key logs, anomaly nodes, root causes, and recommendations. In other words, the AI ​​outputs analysis results, including: problem classification, key log fragments, anomaly nodes, root cause conclusions, and recommended handling directions.

[0087] Based on the above embodiments, the execution process can be summarized as follows: First, the system obtains defect data through the Jira REST API, and parses out problem_description, occurrence_time, and module; then, it calls the fine-tuned cockpit domain NLP model to classify the problem description into: functional anomaly, interface anomaly, communication anomaly, performance anomaly, Crash / ANR, etc.; and according to the fault type and module, it retrieves log_path, keywords, and time_range from the rule base to perform log retrieval and filtering; further, it reads the standard_flow.json (standard process) of the corresponding function, aligns the logs and process nodes by timestamp; thereby performing difference detection, marking abnormal nodes, generating a structured analysis report; and then populating the report back to Jira or pushing it to the development workbench.

[0088] In one possible scenario, the above analysis process also provides a point for human intervention, such as... Figure 3 As shown, Figure 3 This is a schematic diagram illustrating a scenario of a defect handling method provided in one embodiment of this specification. The steps of each module are described below: The user-input problem process can be manually intervened in. Besides platform import, testers can manually enter discovered issues into the system or use automated test cases to automatically report problems. Input typically includes unstructured or semi-structured data such as a description of the problem, the time of occurrence, and environmental information. This data serves as the trigger point and data source for the entire analysis process.

[0089] The problem classification and mapping process can be manually intervened (by module developers). Developers familiar with the business modules can manually map problems to specific functional points based on the observed phenomena (e.g., Bluetooth connection failure, navigation black screen, unresponsive voice wake-up, etc.). This transforms colloquial and vague problem descriptions into clear functional modules or fault types that can be identified by subsequent automated steps, reducing ambiguity in AI classification.

[0090] The process of determining whether a problem falls within the target module's scope is automated using AI. Based on the classification results determined manually in the previous step, the AI ​​assesses whether the current problem falls within the processing range of this module / system. If it doesn't, it may be transferred to another module or process; if it does, it proceeds to the next analysis stage. This achieves automatic task routing and avoids ineffective analysis.

[0091] The log filtering and processing process is automated through AI. Based on preset rules such as keyword sets, time windows, and module paths, it automatically filters relevant log segments from the full log volume. Furthermore, it utilizes scripts like Python to perform preprocessing operations such as log cleaning, format conversion, and timestamp alignment. This transforms the raw, redundant full log volume into concise, structured "effective logs," providing high-quality input for subsequent analysis.

[0092] The problem analysis process is automated through AI, specifically utilizing pre-defined analysis strategies (such as state machine comparison, timing detection, and anomaly code matching) to compare the filtered and processed key logs with normal process logic, identifying abnormal nodes, missing steps, timeouts, and error returns. This enables automated reasoning from logs to root causes, making it the core intelligent component of the entire process.

[0093] The process of outputting conclusions is automated by AI, specifically by providing structured outputs of the analysis results, which may include: problem classification, key log fragments, anomaly nodes, root cause conclusions, and suggested handling directions. The output results can be directly displayed to developers or fed back into a defect management platform (such as Jira). This provides clear and traceable analysis conclusions, supporting rapid remediation decisions.

[0094] As can be seen, the above-mentioned defect handling interaction process, from order retrieval to conclusion, requires no manual operation, achieving full-process automation; log analysis time can be significantly reduced, greatly improving efficiency; it does not rely on development memory and experience, and newcomers can use it directly, reducing personnel dependence; unified log filtering rules and process comparison standards ensure consistent results, achieving standardized analysis; and the continuous accumulation and iteration of work manuals, fault modes, and log characteristics enable knowledge to be preserved.

[0095] In summary, this embodiment first obtains defect information associated with the target application, enabling automatic order retrieval from the defect management platform and eliminating repetitive manual login and copying operations. Then, it performs semantic understanding on the defect information to determine its corresponding preset fault type, transforming unstructured natural language descriptions into structured fault classifications, providing precise instructions for subsequent processing. Based on this, it configures log paths according to preset fault types and obtains associated runtime logs, achieving on-demand and precise log acquisition, replacing manual blind sifting through the entire log volume. Subsequently, it determines the standard process information associated with the runtime logs and compares it with the runtime logs, automatically aligning the actual execution path with the expected standard process to identify deviations. Finally, it analyzes the comparative information to obtain processing operations and outputs root cause conclusions or processing suggestions. This avoids the problems of tedious manual operations, reliance on experience, and low efficiency, improving the accuracy and efficiency of defect handling.

[0096] It should be noted that the various embodiments described in this specification emphasize the parts that differ from other embodiments, and the embodiments can be explained by comparison with each other. Any combination of the various embodiments described in this specification based on general technical knowledge is covered within the scope of this specification.

[0097] In one exemplary embodiment of this specification, an application defect processing apparatus 400 is also provided, such as... Figure 4 As shown, Figure 4 A functional block diagram of a defect handling apparatus for an application provided in one embodiment of this specification, the processing apparatus 400 including: Acquisition unit 401 is used to acquire defect information associated with the target application; Processing unit 402 is used to perform semantic understanding on the defect information in order to determine the preset fault type corresponding to the defect information; The processing unit 402 is further configured to configure a log path according to the preset fault type, so as to obtain the running log associated with the defect information based on the log path; The processing unit 402 is further configured to determine the standard process information associated with the operation log, and compare the standard process information with the operation log to obtain comparison information; The processing unit 402 is further configured to analyze the comparison information to obtain processing operations for the defect information.

[0098] Optionally, in one possible embodiment, performing semantic understanding on the defect information to determine the preset fault type corresponding to the defect information includes: The processing unit 402 is specifically used to call the natural language model associated with the target application, which is obtained by fine-tuning the cockpit domain data; The processing unit 402 is specifically used to perform semantic understanding based on the defect information of the natural language model, so as to determine the semantic information corresponding to the defect information. The processing unit 402 is specifically used to determine the preset fault type corresponding to the defect information based on the semantic information.

[0099] Optionally, in one possible embodiment, determining the preset fault type corresponding to the defect information based on the semantic information includes: The processing unit 402 is specifically used to determine the fault action information corresponding to the defect information based on the semantic information; The processing unit 402 is specifically used to determine the object entity associated with the cockpit domain contained in the semantic information; The processing unit 402 is specifically used to combine the fault action information and the object entity to determine the preset fault type corresponding to the defect information.

[0100] Optionally, in one possible embodiment, configuring a log path according to the preset fault type to obtain the operation log associated with the defect information based on the log path includes: The processing unit 402 is specifically used to determine the time window and functional modules for the defect information indication; The processing unit 402 is specifically used to configure the log path according to the functional module and the preset fault type; The processing unit 402 is specifically used to obtain the set of keywords indicating the preset fault type; The processing unit 402 is specifically used to filter the logs associated with the keyword set according to the time window and the log path to obtain the running logs associated with the defect information.

[0101] Optionally, in one possible embodiment, the step of filtering logs associated with the keyword set according to the time window and the log path to obtain the runtime logs associated with the defect information includes: The processing unit 402 is specifically used to obtain the reference window parameters of the preset fault type indication; The processing unit 402 is specifically used to adjust the time window according to the reference window parameters; The processing unit 402 is specifically used to determine the target information source that is adapted to the adjusted time window; The processing unit 402 is specifically used to filter the logs of the target information source by referring to the keyword set through the log path according to the adjusted time window, so as to obtain the running logs associated with the defect information.

[0102] Optionally, in one possible embodiment, determining the standard process information associated with the runtime log and comparing the standard process information with the runtime log to obtain comparison information includes: The processing unit 402 is specifically used to determine the standard process information associated with the running log, and to determine the process nodes included in the standard process information; The processing unit 402 is specifically used to align information according to the process nodes based on the timestamps of the running log to obtain a comparison sequence; The processing unit 402 is specifically used to determine the status information and execution information indicated by the alignment sequence; The processing unit 402 is specifically used to compare the standard process information with the running log based on the status information and the execution information.

[0103] Optionally, in one possible embodiment, the processing unit 402 is specifically used to analyze the comparison information to obtain abnormal nodes; The processing unit 402 is specifically used to determine the differential log fragment associated with the abnormal node; The processing unit 402 is specifically used to determine the processing operation for the defect information based on the root cause classification indicated by the difference log fragment.

[0104] Specifically, the processing unit and acquisition unit in this embodiment can correspond to physical components. For example, the processing unit can be a processing module such as a CPU, GPU, or FPGA. The specific physical component can be any component or combination of components with the above functions. The specific method depends on the actual scenario and is not limited here.

[0105] The aforementioned processing device first acquires defect information associated with the target application, enabling automatic order retrieval from the defect management platform and eliminating repetitive manual login and copying operations. Next, it performs semantic understanding on the defect information to determine its corresponding preset fault type, transforming unstructured natural language descriptions into structured fault classifications, providing precise instructions for subsequent processing. Based on this, it configures log paths according to preset fault types and acquires associated runtime logs, achieving on-demand and precise log acquisition, replacing manual blind sifting through the entire log volume. Subsequently, it determines the standard process information associated with the runtime logs and compares it with the runtime logs, automatically aligning the actual execution path with the expected standard process to identify deviations. Finally, through comparative analysis of the information, it obtains processing operations and outputs root cause conclusions or processing suggestions. This avoids the problems of cumbersome manual operations, reliance on experience, and low efficiency, improving the accuracy and efficiency of defect processing.

[0106] Specific limitations regarding the defect handling device for the application can be found in the limitations regarding the defect handling method for the application described above, and will not be repeated here. Each unit module in the aforementioned defect handling device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device in hardware form, or stored in the memory of a computer device in software form, so that the processor can call and execute the operations corresponding to each module.

[0107] In addition, in one exemplary embodiment of this specification, a vehicle is also provided, such as Figure 5 As shown, Figure 5This is a structural schematic diagram of a vehicle provided for one embodiment of this specification.

[0108] For example, vehicle 500 and Figure 1 Vehicle 120 in the text refers to the same vehicle.

[0109] For example, such as Figure 5 As shown, the vehicle 500 includes a memory 510 and a processor 520, wherein the memory 510 stores executable program code 530, and the processor 520 is used to call and execute the executable program code 530 to perform a method for handling defects in an application.

[0110] For example, the memory 510 can be used to store related programs of the application defect handling method provided in the embodiments of this application; the processor 520 can call the related programs of the application defect handling method stored in the memory 510 to execute the application defect handling method of the embodiments of this application; for example, by obtaining defect information associated with the target application; performing semantic understanding on the defect information to determine the preset fault type corresponding to the defect information; configuring a log path according to the preset fault type to obtain the running log associated with the defect information based on the log path; determining the standard process information associated with the running log, and comparing the standard process information with the running log to obtain comparison information; and analyzing the comparison information to obtain the processing operation for the defect information.

[0111] This embodiment can divide the device into functional modules based on the above method example. For example, each module can correspond to a separate function, or two or more functions can be integrated into one processing module. The integrated module can be implemented in hardware. It should be noted that the module division in this embodiment is illustrative and only represents one logical functional division. In actual implementation, there may be other division methods.

[0112] When each functional module is divided according to its corresponding function, the device may further include an acquisition module, a prediction module, a determination module, and an output module. It should be noted that all relevant content regarding the steps involved in the above method embodiments can be referenced to the functional descriptions of the corresponding functional modules, and will not be repeated here.

[0113] It should be understood that the apparatus provided in this embodiment is used to perform the defect handling method of the above-described application, and therefore can achieve the same effect as the above-described implementation method.

[0114] When using an integrated unit, the device may include a processing module and a storage module. When the device is applied to a vehicle, the processing module can be used to control and manage the vehicle's movements. The storage module can be used to support the vehicle in executing program code, etc.

[0115] The processing module may be a processor or a controller, which can implement or execute various exemplary logic blocks, modules, and circuits as disclosed in this application. The processor may also be a combination of computing functions, such as a combination of one or more microprocessors, a combination of digital signal processing (DSP) and microprocessors, etc., and the storage module may be a memory.

[0116] In addition, the apparatus provided in the embodiments of this application may specifically be a chip, component or module. The chip may include a connected processor and a memory. The memory is used to store instructions. When the processor calls and executes the instructions, the chip can execute a defect handling method for an application provided in the above embodiments.

[0117] This application also provides a computer-readable storage medium storing computer program code, which, when run on a computer, causes the computer to execute the aforementioned related method steps to implement a defect handling method for an application provided in the above embodiments. The computer-readable storage medium may include, but is not limited to, any type of disk, including floppy disks, optical disks, Digital Video Discs (DVDs), Compact Disc Read-Only Memory (CD-ROMs), microdrives, and magneto-optical disks, read-only memory (ROMs), random access memory (RAMs), erasable programmable read-only memory (EPROMs), electrically erasable programmable read-only memory (EEPROMs), dynamic random access memory (DRAMs), video random access memory (VRAMs), flash memory devices, magnetic cards or optical cards, nanosystems (including molecular memory ICs), or any type of medium or device suitable for storing instructions and / or data.

[0118] This application also provides a computer program product that, when run on a computer, causes the computer to perform the aforementioned related steps to implement a defect handling method for an application provided in the above embodiments.

[0119] The vehicle, computer-readable storage medium, computer program product or chip provided in this application are all used to execute the corresponding methods provided above. Therefore, the beneficial effects that can be achieved can be referred to the beneficial effects of the corresponding methods provided above, and will not be repeated here.

[0120] Through the above description of the embodiments, those skilled in the art will understand that, for the sake of convenience and brevity, only the division of the above functional modules is used as an example. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above.

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

[0122] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0123] The embodiments described above are merely illustrative of several implementation methods outlined in this specification. While the descriptions are specific and detailed, they should not be construed as limiting the scope of the solutions provided in this specification. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this specification, and these all fall within the scope of protection of this specification. Therefore, the scope of protection for this patent should be determined by the appended claims.

Claims

1. A defect handling method for an application, characterized in that, include: Obtain defect information associated with the target application; Perform semantic understanding on the defect information to determine the preset fault type corresponding to the defect information; Configure the log path according to the preset fault type, so as to obtain the running log associated with the defect information based on the log path; Determine the standard process information associated with the operation log, and compare the standard process information with the operation log to obtain comparison information; By analyzing the comparison information, processing operations can be obtained for the defect information.

2. The method according to claim 1, characterized in that, The step of performing semantic understanding on the defect information to determine the preset fault type corresponding to the defect information includes: The natural language model associated with the target application is invoked; the natural language model is fine-tuned using cockpit domain data. Semantic understanding is performed based on the defect information in the natural language model to determine the semantic information corresponding to the defect information; Based on the semantic information, the preset fault type corresponding to the defect information is determined.

3. The method according to claim 2, characterized in that, The step of determining the preset fault type corresponding to the defect information based on the semantic information includes: Based on the semantic information, determine the fault action information corresponding to the defect information; Identify the object entities associated with the cockpit domain contained in the semantic information; By combining the fault action information and the object entity, the preset fault type corresponding to the defect information is determined.

4. The method according to claim 1, characterized in that, The step of configuring a log path according to the preset fault type, and obtaining the operation log associated with the defect information based on the log path, includes: Determine the time window and functional module for indicating the defect information; Configure the log path according to the functional modules and the preset fault types; Obtain the set of keywords indicating the preset fault type; The logs associated with the keyword set are filtered according to the time window and the log path to obtain the running logs associated with the defect information.

5. The method according to claim 4, characterized in that, The step of filtering logs associated with the keyword set according to the time window and the log path to obtain the runtime logs associated with the defect information includes: Obtain the reference window parameters of the preset fault type indication; The time window is adjusted according to the reference window parameters; Identify the target information sources that are compatible with the adjusted time window; According to the adjusted time window, the logs of the target information source are filtered by referring to the keyword set through the log path to obtain the running logs associated with the defect information.

6. The method according to claim 1, characterized in that, The step of determining the standard process information associated with the operation log and comparing the standard process information with the operation log to obtain comparison information includes: Determine the standard process information associated with the operation log, and determine the process nodes included in the standard process information; Based on the timestamps of the running logs, information is aligned according to the process nodes to obtain a comparison sequence; Determine the status information and execution information indicated by the alignment sequence; The comparison information between the standard process information and the operation log is based on the status information and the execution information.

7. The method according to claim 1, characterized in that, The step of analyzing the comparison information to obtain processing operations for the defect information includes: By analyzing the comparison information, abnormal nodes can be identified. Identify the differential log fragment associated with the abnormal node; Based on the root cause classification indicated by the difference log fragment, determine the processing operation for the defect information.

8. A vehicle, characterized in that, The vehicles include: Memory, used to store executable program code; A processor for calling and running the executable program code from the memory, causing the vehicle to perform the defect handling method of the application as described in any one of claims 1 to 7.

9. An electronic device, characterized in that, It includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor, when executing the computer program, implements the defect handling method of the application according to any one of claims 1 to 7.

10. A non-transitory computer-readable storage medium, characterized in that, The non-transitory computer-readable storage medium stores computer instructions for causing a computer to perform the method according to any one of claims 1 to 8.

Images