Vehicle-mounted operating system intelligent diagnosis method and device and vehicle

Abstract

The application relates to the technical field of intelligent diagnosis of vehicle-mounted operating systems, in particular to an intelligent diagnosis method and device for a vehicle-mounted operating system and a vehicle, wherein the method comprises the following steps: obtaining historical diagnosis data of the vehicle-mounted operating system, wherein the historical diagnosis data comprises at least one of historical logs, fault diagnosis results and a diagnosis rule library; performing block vectorization on the historical diagnosis data, constructing a vector database and storing the vector database in a local knowledge base, and searching current log data based on the knowledge base to obtain a search result; generating a training data set according to the fault diagnosis data and fine-tuning a large language model. The current log data and a target diagnosis task are input into the fine-tuned large language model, the fine-tuned large language model calls the local knowledge base to execute the diagnosis task, and a fault diagnosis result is generated based on the search result. Therefore, the problems that the fault diagnosis of the vehicle-mounted operating system in the related art depends on artificial experience or fixed rules, cannot dynamically fuse and intelligently infer, and is low in accuracy are solved.

Description

Technical Field

[0001] This application relates to the field of intelligent diagnostic technology for vehicle operating systems, and in particular to an intelligent diagnostic method, device and vehicle for vehicle operating systems. Background Technology

[0002] Troubleshooting in-vehicle operating systems requires extensive knowledge and experience, and involves methods such as log analysis and system restarts. Therefore, diagnosing in-vehicle operating systems relies on manual experience or fixed rules, lacking dynamic integration and intelligent reasoning, resulting in low accuracy. Summary of the Invention

[0003] This application provides a method, device, and vehicle for intelligent diagnosis of vehicle operating systems, in order to solve the problems in related technologies where vehicle operating system fault diagnosis relies on human experience or fixed rules, cannot dynamically integrate and perform intelligent reasoning, resulting in low accuracy.

[0004] The first aspect of this application provides an intelligent diagnostic method for an in-vehicle operating system, comprising the following steps: acquiring historical diagnostic data of the in-vehicle operating system, the historical diagnostic data including at least one of historical log data, fault diagnosis result data, and a diagnostic rule base of the in-vehicle operating system; performing block-based vectorization transformation on the historical diagnostic data to obtain vectorized data, constructing a local knowledge base using a vector database, storing the vectorized data using the local knowledge base, retrieving the current log data of the in-vehicle operating system using the local knowledge base to obtain retrieval results; generating a training dataset based on the fault diagnosis data, fine-tuning a large language model using the dataset, inputting the current log data and the target diagnostic task into the fine-tuned large language model, the fine-tuned large language model calling the local knowledge base to execute the target diagnostic task, and generating fault diagnosis results based on the retrieval results.

[0005] Optionally, a local knowledge base can be constructed using a vector database, including: identifying knowledge source files in the vector database; parsing the knowledge source files and generating string text based on the parsing results; mapping the string text to fixed-length vectors, adjusting the weights of the fixed-length vectors according to the field names of the string texts, and writing the fixed-length vectors into the vector database to construct the local knowledge base.

[0006] Optionally, the diagnostic process of the fine-tuned large language model includes: determining whether to call local tools based on the current log data; if local tools are needed, processing the current log data using local tools and inputting the processing results into the fine-tuned large language model; if local tools are not needed, performing a search operation on the local knowledge base to obtain search results and generating fault diagnosis results based on the search results.

[0007] Optionally, determine whether to call local tools based on the current log data, including: inputting the current log data into the agent, which has a tool list and function description prompt template pre-set within the agent, the agent calling the prompt template and tool list, and outputting the call result of the local tools.

[0008] Optionally, the processing flow of the intelligent agent includes: injecting the current log data into the prompt word template, the prompt word template outputting the functional description of the current log data, matching local tools based on the tool list, the tool list including toolsets, and the toolsets including data pairs of multiple local tools and functional descriptions; if a local tool is matched based on the tool list, it is determined that the local tool needs to be called; if no local tool is matched based on the tool list, it is determined that the local tool does not need to be called.

[0009] Optionally, local tools are used to process the current log data, including: extracting the format features and semantic features of the current log data; inputting the format features and semantic features into a log type template, and the log type template outputs the classification results of the current log data; performing dual-channel parallel filtering on the classified current log data, deleting duplicate logs in the filtered current log data, and performing context association processing on the current log data to obtain context log clusters.

[0010] Optionally, the dual channels include a keyword channel and a level marker channel. The keyword channel includes: building a dynamic regular expression engine and using the dynamic regular expression engine to add pre-set domain keywords to the current log data; the level marker channel parses the level identifier of the current log data, determines the log priority in the current log data based on the level identifier, and extracts logs based on the log priority.

[0011] Optionally, the target diagnostic task includes user-input prompt text, wherein the prompt text includes at least one of the following: role description text of the large language model, question description text during local knowledge base query, tool description text of the local tool, output format description text of the large language model, role description text of the local tool, and output format description text of the local tool.

[0012] A second aspect of this application provides an intelligent diagnostic device for an in-vehicle operating system, comprising: an acquisition module for acquiring historical diagnostic data of the in-vehicle operating system, the historical diagnostic data including at least one of historical log data, fault diagnosis result data, and a diagnostic rule base of the in-vehicle operating system; a construction module for performing block-based vectorization transformation on the historical diagnostic data to obtain vectorized data, constructing a local knowledge base using a vector database, storing the vectorized data using the local knowledge base, and retrieving current log data of the in-vehicle operating system using the local knowledge base to obtain retrieval results; and a diagnostic module for generating a training dataset based on the fault diagnosis data, fine-tuning a large language model using the dataset, inputting the current log data and the target diagnostic task into the fine-tuned large language model, the fine-tuned large language model calling the local knowledge base to execute the target diagnostic task, and generating fault diagnosis results based on the retrieval results.

[0013] A third aspect of this application provides a vehicle, including: a memory, a processor, and a computer program stored in the memory and executable on the processor. The processor executes the program to implement the intelligent diagnostic method for the vehicle operating system as described in the above embodiments.

[0014] Therefore, this application has at least the following beneficial effects: This application embodiment can acquire historical diagnostic data of the vehicle operating system, including at least one of historical logs, fault diagnosis results, and a diagnostic rule base. The historical diagnostic data is segmented and vectorized, and a vector database is used to construct and store it in a local knowledge base. Based on this knowledge base, current log data is retrieved to obtain search results. Then, a training dataset is generated based on the fault diagnosis data, and a large language model is fine-tuned. The current log data and the target diagnostic task are input into the fine-tuned large language model. The fine-tuned large language model calls the local knowledge base to execute the diagnostic task and generates fault diagnosis results based on the search results. By fusing historical logs, fault diagnosis results, and the rule base to construct the local knowledge base, and combining this with the retrieval-enhanced fine-tuned large language model to execute the diagnostic task, fault diagnosis results can be automatically and accurately generated, significantly improving accuracy and reducing reliance on manual intervention. This solves the problems in related technologies where vehicle operating system fault diagnosis relies on human experience or fixed rules, cannot dynamically integrate and perform intelligent reasoning, leading to low accuracy.

[0015] Additional aspects and advantages of this application will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of this application. Attached Figure Description

[0016] The above and / or additional aspects and advantages of this application will become apparent and readily understood from the following description of the embodiments taken in conjunction with the accompanying drawings, wherein: Figure 1This is a flowchart of an intelligent diagnostic method for an in-vehicle operating system provided according to an embodiment of this application; Figure 2 This is a schematic diagram illustrating the process of building a local knowledge base using an in-vehicle gateway according to an embodiment of this application; Figure 3 This is a schematic diagram of the diagnostic process of a large language model for an in-vehicle operating system according to an embodiment of this application; Figure 4 This is a schematic diagram of the vehicle operating system log preprocessing process according to an embodiment of this application; Figure 5 This is an architecture diagram of an intelligent diagnostic system for an in-vehicle operating system provided according to an embodiment of this application; Figure 6 This is a schematic diagram illustrating the specific process of intelligent diagnosis of an in-vehicle operating system according to an embodiment of this application; Figure 7 This is a block diagram of an intelligent diagnostic device for an in-vehicle operating system provided according to an embodiment of this application; Figure 8 This is a structural schematic diagram of a vehicle provided according to an embodiment of this application. Detailed Implementation

[0017] The embodiments of this application are described in detail below. Examples of the embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and intended to explain this application, and should not be construed as limiting this application.

[0018] The diagnosis of faults in automotive operating systems relies excessively on human experience. Engineers must troubleshoot using traditional methods such as log analysis and system restarts, which are time-consuming, inefficient, and easily limited by individual experience. Furthermore, the knowledge required for diagnosis is scattered among experts in different fields, lacking a unified knowledge base. While intelligent diagnostic methods in related technologies often rely on fixed models or rules, they struggle to adapt to complex and varied fault types and are limited by data scarcity, insufficient generalization ability, and difficulties in cross-domain integration, resulting in low diagnostic accuracy.

[0019] The following description, with reference to the accompanying drawings, outlines an intelligent diagnostic method, apparatus, and vehicle for an in-vehicle operating system according to embodiments of this application. Addressing the issue mentioned in the background art where in-vehicle operating system fault diagnosis relies on manual experience or fixed rules, failing to dynamically integrate and perform intelligent reasoning, resulting in low accuracy, this application provides an intelligent diagnostic method for an in-vehicle operating system. This method acquires historical diagnostic data of the in-vehicle operating system, including at least one of historical logs, fault diagnosis results, and a diagnostic rule base. The historical diagnostic data is segmented and vectorized, and a vector database is used to construct and store it in a local knowledge base. Based on this knowledge base, current log data is retrieved to obtain search results. Then, a training dataset is generated based on the fault diagnosis data, and a large language model is fine-tuned. The current log data and the target diagnostic task are input into the fine-tuned large language model. The fine-tuned large language model calls the local knowledge base to execute the diagnostic task and generates fault diagnosis results based on the search results. By integrating historical logs, fault diagnosis results, and the rule base to construct a local knowledge base, and combining this with a retrieval-enhanced fine-tuned large language model to execute the diagnostic task, fault diagnosis results can be automatically and accurately generated, significantly improving accuracy and reducing reliance on manual intervention. This solves the problem in related technologies where fault diagnosis of in-vehicle operating systems relies on human experience or fixed rules, and cannot dynamically integrate and perform intelligent reasoning, resulting in low accuracy.

[0020] Specifically, Figure 1 This is a flowchart of an intelligent diagnostic method for an in-vehicle operating system provided in an embodiment of this application.

[0021] like Figure 1 As shown, the intelligent diagnostic method for the vehicle operating system includes the following steps: In step S101, historical diagnostic data of the vehicle operating system is obtained. The historical diagnostic data includes at least one of the historical log data of the vehicle operating system, fault diagnosis result data, and diagnostic rule base.

[0022] Historical log data refers to the actual log information generated within the vehicle operating system, including system logs, kernel logs, application crash stacks, and performance monitoring metrics; fault diagnosis result data refers to fault category labels and corresponding solutions obtained after analyzing historical logs; and the diagnostic rule base refers to a structured technical document containing problem types, log retrieval types, diagnostic keywords, and handling solutions, such as an Excel-formatted rule table.

[0023] It is understood that the embodiments of this application can integrate scattered diagnostic knowledge into structured input by acquiring historical diagnostic data, including historical log data, fault diagnosis result data, and diagnostic rule base, thereby laying a data foundation for building a local knowledge base and realizing automated diagnosis, and effectively alleviating the problem of manual dependence caused by knowledge fragmentation.

[0024] In step S102, the historical diagnostic data is divided into blocks and vectorized to obtain vectorized data. A local knowledge base is constructed using a vector database, the vectorized data is stored in the local knowledge base, and the current log data of the vehicle operating system is retrieved using the local knowledge base to obtain retrieval results.

[0025] Among them, segmented vectorization refers to the process of converting historical diagnostic data into fixed-length vectors after segmenting it according to text content using an embedding model; vectorized data refers to numerical vectors generated by the embedding model to represent the semantics of the original diagnostic knowledge; and the local knowledge base refers to a knowledge base built on the Chroma vector database and used to store vectorized data to support dynamic updates and top-k similarity retrieval.

[0026] It is understood that the embodiments of this application can obtain structured storage and semantic-level retrieval capabilities for vehicle operating system fault knowledge by dividing historical diagnostic data into blocks and vectorizing them and building a local knowledge base. This enables the system to quickly and accurately match relevant historical experience from the current logs during diagnosis, thereby improving the efficiency of knowledge reuse.

[0027] In some embodiments, constructing a local knowledge base using a vector database includes: identifying knowledge source files in the vector database; parsing the knowledge source files and generating string text based on the parsing results; mapping the string text to fixed-length vectors, adjusting the weights of the fixed-length vectors according to the field names of the string texts, and writing the fixed-length vectors into the vector database to construct the local knowledge base.

[0028] Among them, knowledge source file refers to the original structured document containing diagnostic knowledge; string text refers to a uniformly formatted string generated by concatenating the field names and field values ​​of the knowledge source file; fixed-length vector refers to a semantic vector with fixed dimensions obtained by mapping the string text through an embedding model.

[0029] Specifically, such as Figure 2 As shown, the process of building a local knowledge base includes: In step 201, the knowledge source files in the vector database are identified.

[0030] In step 202, structural analysis and text generation are performed.

[0031] Specifically, for Excel-formatted knowledge source files, field names and values ​​are concatenated into a uniform format string to preserve the original structural information, i.e., Sheet name + field name + field content, which facilitates subsequent embedding coding's understanding of the contextual semantics. For example: Sheet1: Problem type: Display problem; Log retrieval type: System log; Diagnostic keyword: Oops; Solution: Uninstall the exception module.

[0032] In step 203, Embedding encoding is performed.

[0033] Specifically, the converted string text is mapped to a fixed-length vector, and the formula for adjusting the weights of the fixed-length vectors based on the importance of the field names is as follows:

[0034] in, For fields; For the embedded variables corresponding to the respective fields; A fixed-length vector obtained by weighted summation of the embedding vectors for each field.

[0035] In step 204, a fixed-length vector is written into the vector database.

[0036] Specifically, the fixed-length vector is written to the vector database using the interface provided by ChromaDB (Chroma Database, an open-source vector database), and a top-k similarity search is performed, that is, the top k results with the highest similarity to the query vector are returned.

[0037] In step 205, the current log data of the vehicle operating system is retrieved using the local knowledge base to obtain the retrieval results.

[0038] It is understood that the embodiments of this application can obtain a high-precision knowledge representation that retains the original semantic structure by converting the structured knowledge source file into a fixed-length vector with field weights and storing it in a vector database, thereby improving the relevance and diagnostic accuracy of subsequent retrieval.

[0039] In step S103, a training dataset is generated based on the fault diagnosis data. The large language model is then fine-tuned using the dataset. The current log data and the target diagnosis task are input into the fine-tuned large language model. The fine-tuned large language model calls the local knowledge base to execute the target diagnosis task and generates fault diagnosis results based on the retrieval results.

[0040] The training dataset refers to a collection of historical log data and corresponding fault diagnosis results, which is cleaned, labeled, and used for model fine-tuning. The large language model refers to a lightweight, general-purpose large model deployed locally. The target diagnosis task refers to a fault diagnosis request initiated by the user, which includes the current log data to be analyzed and the specific diagnostic intent. The fault diagnosis result refers to the fault cause and corresponding solution output by the model.

[0041] It should be noted that the fault diagnosis results are populated by retrieving relevant knowledge from the vector database to provide non-public knowledge to the large language model, so as to generate the results required by the tool more accurately.

[0042] It is understood that the embodiments of this application can obtain a precise understanding and reasoning ability of complex faults in the vehicle operating system by using fault diagnosis data to fine-tune the large language model and combining it with the local knowledge base retrieval results to generate diagnostic output, thereby significantly improving diagnostic accuracy and reducing reliance on human experience.

[0043] Specifically, the large language model is based on the Transformer architecture and mainly consists of an encoder-decoder structure. The basic units of the large language model are multi-head self-attention layers and feedforward neural networks. Residual connections and layer normalization are used between layers to facilitate information flow and stabilize the training process. The activation function used is GELU (Gaussian Error Linear Unit), which can efficiently handle natural language processing tasks and effectively capture non-linear features.

[0044] When fine-tuning the large language model, the training dataset is primarily derived from historical diagnostic data of the vehicle operating system, including historical logs, fault diagnosis results, and a diagnostic rule base. Data preprocessing steps include text cleaning (removing irrelevant characters), word segmentation (using tokenization), and vectorization (using word embedding). The difference between the model output and the true labels is evaluated using the cross-entropy loss function, and AdamW is selected as the optimization algorithm to adapt to dynamic learning rate adjustments and ensure better convergence.

[0045] Furthermore, the selection of key hyperparameters in the large language model mainly includes the learning rate, batch size, and number of training epochs. The learning rate is initially set to 1e-5 and dynamically adjusted based on model convergence, using a learning rate decay strategy. The batch size is set to 32 to balance training time and model performance. The number of training epochs is adjusted based on changes in accuracy on the validation set, typically ranging from 5 to 10 epochs. For optimization strategies, early stopping and learning rate scheduling are combined to prevent overfitting and further improve model performance.

[0046] Finally, a series of experiments were conducted to compare the performance of the large language model before and after fine-tuning in fault diagnosis. The results showed that the fine-tuned large language model improved the recognition rate of different fault types by more than 20% compared to the un-fine-tuned model, especially in complex fault situations, where its accuracy reached 90%; while the accuracy of the un-fine-tuned model was only around 65%. Furthermore, by incorporating a local knowledge base, the large language model's response speed when processing real-time log data improved by 30%, further validating the practical application effect of intelligent diagnostic methods in vehicle operating system fault diagnosis and demonstrating the necessity of fine-tuning the large language model.

[0047] Specifically, for in-vehicle operating system fault diagnosis tasks, fine-tuning the base language model is key to achieving efficient fault detection and diagnosis. The fine-tuning of the language model aims to optimize the general-purpose language model, adapting it to the specific needs of in-vehicle operating system fault diagnosis and improving its performance and contextual relevance in the specialized domain. Through fine-tuning, the language model learns the terminology, log formats, and reasoning logic specific to in-vehicle operating system fault diagnosis, significantly improving diagnostic accuracy.

[0048] The data preparation process includes data acquisition, annotation processing, and formatted storage. (1) First, collect the historical log data and fault diagnosis results of the vehicle operating system. The historical log data includes system logs (such as dmesg and Kernel panic, which are used to provide kernel-level error information to diagnose system anomalies), application crash stacks (used to locate the specific location where the problem occurred), performance monitoring indicators (such as CPU, memory and IO usage, which are used to reflect system resource bottlenecks or anomalies) and CAN bus fault codes (used to provide hardware fault information during vehicle operation).

[0049] (2) The collected log fragments are then classified and labeled, and fault category labels are assigned according to the content, such as memory leak, driver deadlock or hardware interruption. Key fields such as timestamp, module name and error code are extracted during the labeling process to support subsequent diagnostic analysis.

[0050] (3) Finally, the labeled data is formatted and stored, and database or log management tools are used to ensure efficient access and management, providing high-quality training data support for fine-tuning of large language models.

[0051] Supervised learning trains models to identify common fault patterns using a large amount of labeled historical fault data. In supervised learning for fault diagnosis of automotive operating systems, Random Forest is used to ensemble multiple decision trees for prediction. This effectively reduces overfitting and has a strong ability to handle correlations between features, making it suitable for processing multi-dimensional data in automotive operating systems. Methodologically, Random Forest is used to classify fault categories, and the tree structure is used to automatically select features for diagnosis. Supervised learning minimizes the error between the predicted results and the actual labels, allowing the model to gradually master various fault characteristics.

[0052] Secondly, reinforcement learning training can be used to optimize the decision-making process for fault diagnosis. Deep Q-Networks (DQNs) combine deep neural networks and Q-learning, enabling them to handle various sensor data and environmental inputs from automotive operating systems. By approximating the Q-value through deep learning, they address the problem of excessively large state spaces in traditional Q-learning. Methodologically, deep neural networks approximate the Q-function, enhancing the system's judgment and response capabilities in complex fault situations. During reinforcement learning, DQN receives feedback through interaction with the diagnostic environment, gradually adjusting its decision-making strategy to achieve better fault diagnosis results. For automotive operating systems, reinforcement learning can optimize fault detection and repair strategies based on continuous simulation and actual operational feedback, enabling the diagnostic model to make optimal diagnostic and response measures in changing operating environments, thereby improving overall system performance. Combining the above-mentioned supervised learning and reinforcement learning methods, model fine-tuning not only enhances the accuracy of fault diagnosis in automotive operating systems but also improves their ability to cope with complex situations, ultimately achieving efficient and accurate fault diagnosis.

[0053] In some embodiments, the diagnostic process of the fine-tuned large language model includes: determining whether to call local tools based on the current log data; if local tools are needed, processing the current log data using local tools and inputting the processing results into the fine-tuned large language model; if local tools are not needed, performing a retrieval action by calling the local knowledge base to obtain retrieval results and generating fault diagnosis results based on the retrieval results.

[0054] Log data refers to the actual log information generated by the vehicle operating system during operation; local tools refer to dedicated analysis tools pre-installed in the diagnostic system.

[0055] It is understood that the embodiments of this application can dynamically determine whether to call local tools based on the current log data, and generate diagnoses by combining the tool processing results or knowledge base retrieval results, thereby obtaining adaptive processing capabilities for different fault scenarios and improving the flexibility and accuracy of the diagnostic process.

[0056] Specifically, such as Figure 3 As shown, the diagnostic process for large language models specifically includes: In step 301, the user first enters a description of the problem or task.

[0057] In step 302, after receiving user input, the agent enters a decision point and uses a large language model to analyze and determine whether the user's question or task description requires the use of local tools. If tools are required, the agent invokes the appropriate tools based on the task description.

[0058] Specifically, if tools are needed, a description such as "Help me analyze system logs" can be generated, and then the corresponding tool can be invoked based on the task description. If tools are not needed, a description such as "My vehicle's operating system is unresponsive. What could be causing this, and how should I resolve it?" can be generated, and then subsequent operations can be performed.

[0059] It should be noted that the tool also has the ability to call large language models and retrieve relevant question-and-answer records from vector databases in order to generate better response content.

[0060] In step 303, if no tool is required, the agent will retrieve relevant question-and-answer records from the vector database.

[0061] In step 304, the retrieved information is used to enhance the response capability of the large language model, which then generates a response autonomously based on the retrieved information.

[0062] In step 305, the input and output content is cached, the input and output history is recorded, and the user input is returned for later reference or tracing.

[0063] In step 306, it is determined whether the task has been completed.

[0064] In step 307, if the task has not yet been completed, a description of the next task will be generated, and the process will return to the decision point. The newly generated description of the next task will be re-analyzed through the large model to determine whether the tool is needed. This process will continue until the task is completed.

[0065] In some embodiments, determining whether to invoke local tools based on current log data includes: inputting current log data into an agent, which has a tool list and function description prompt template pre-set within the agent, the agent invoking the prompt template and tool list, and outputting the invocation result of the local tools.

[0066] Among them, the intelligent agent refers to a program module built based on fine-tuning a large language model and capable of autonomously deciding whether to call tools and perform diagnostic tasks based on input logs; the tool list refers to a pre-built set of available local tools; and the prompt word template refers to structured prompt words, which include role descriptions, tool descriptions, output specifications, etc., and are used to guide the large model to determine whether to call tools.

[0067] It is understood that the embodiments of this application can obtain the ability to automatically match and decide to call appropriate local tools by inputting the current log into the built-in tool list and prompt word templates, thereby avoiding manual intervention and improving the accuracy of tool calls and the level of automation of the diagnostic process.

[0068] In some embodiments, the processing flow of the intelligent agent includes: injecting current log data into a prompt word template, the prompt word template outputting a functional description of the current log data, matching local tools based on a tool list, the tool list including a toolset, the toolset including multiple data pairs of local tools and functional descriptions; if a local tool is matched based on the tool list, it is determined that the local tool needs to be called; if no local tool is matched based on the tool list, it is determined that the local tool does not need to be called.

[0069] In this context, a toolset refers to a collection of data pairs containing multiple local tools and their corresponding function descriptions within a toolset list.

[0070] It is understood that the embodiments of this application generate a function description by injecting the current log into the prompt word template and matching it with the tool-function description pair in the tool set, thereby obtaining the ability to automatically determine whether to call local tools based on semantics, and realizing the precision and automation of tool selection in the diagnostic process.

[0071] Specifically, when receiving raw log input, a structured prompt word template is automatically injected. The prompt word template contains a toolset from the tool library: toolset = { (tool name 1, function description 1), (tool name 2, function description 2), ...}.

[0072] In some embodiments, local tools are used to process the current log data, including: extracting the format features and semantic features of the current log data; inputting the format features and semantic features into a log type template, and the log type template outputs the classification results of the current log data; performing dual-channel parallel filtering on the classified current log data, deleting duplicate logs in the filtered current log data, and performing context association processing on the current log data to obtain a context log cluster.

[0073] Among them, format features refer to fixed structured fields in the log; semantic features refer to the fault semantic information expressed by the log content, such as error keywords, abnormal behavior descriptions, etc.; log type templates refer to a predefined log classification rule base; and context log clusters refer to a set of related logs aggregated based on time windows, TAG consistency, and content semantic relevance.

[0074] It is understood that the embodiments of this application classify, dual-channel filter, deduplicate, and context-associate the current log extraction format and semantic features to obtain log input with clear structure, less redundancy, and complete semantics, which significantly improves the accuracy of subsequent diagnostic models in identifying the root causes of faults.

[0075] Specifically, such as Figure 4 As shown, the process of processing the current log data using local tools includes: In step 401, log data is entered.

[0076] In step 402, the tool call makes dynamic decisions. The fine-tuned large language model dynamically decides whether to call the tool for processing based on the matching degree between the log content and the tool description, thus realizing an automated tool selection mechanism.

[0077] In step 403, the current log data is categorized.

[0078] Specifically, a log type template library is established, classifying logs according to their format and semantic features. Log type template library: Template = { "logcat log": { "date and time" | "PID" | "log level" | "TAG" | "log content"}, …}.

[0079] In step 404, the current log data that has been classified is subjected to parallel filtering through two channels.

[0080] In step 405, duplicate logs in the filtered current log data are deleted.

[0081] Specifically, to address duplicate logs caused by automatic restarts after a service crash, a deduplication feature vector and similarity criteria are defined to retain only the first occurrence of a log entry, eliminating redundant data generated by service restarts. For example, the deduplication feature vector includes dimensions such as Tag_hash and content_Jaccard.

[0082] In step 406, context association processing is performed on the current log data to obtain a context log cluster.

[0083] Specifically, to improve the depth and accuracy of problem diagnosis, a contextual association is constructed for each error log, including the following three dimensions: time window: retrieving adjacent logs within ±5 seconds of the log's timestamp; tag consistency: filtering logs with the same tag; and content relevance: identifying logs with overlapping keywords through semantic similarity algorithms. Finally, the association results are integrated into a contextual log cluster.

[0084] In step 407, the chunked processing is used for analysis of the large language model.

[0085] Specifically, to avoid the problem of the large language model being overloaded when processing data in a single run, the log set is divided into blocks according to a preset capacity threshold, namely L_max. The blocks are then input into the large language model in batches, and the analysis results of each batch are aggregated to generate the final report.

[0086] In step 408, the preprocessed and segmented log data is input into the large language model for fault diagnosis.

[0087] In some embodiments, the dual channels include a keyword channel and a level marker channel. The keyword channel includes: constructing a dynamic regular expression engine and using the dynamic regular expression engine to add pre-set domain keywords to the current log data; the level marker channel includes: parsing the level identifier of the current log data, determining the log priority in the current log data based on the level identifier, and extracting logs based on the log priority.

[0088] The keyword channel refers to a filtering channel that filters logs by matching preset error keywords, such as error, fail, exception, crash, timeout, or the vehicle control domain term CAN_Error; the level marker channel refers to a filtering channel that extracts high-priority logs by parsing level identifiers in the logs, such as E=Error, I=Info, D=Debug; the dynamic regular expression engine refers to a regular expression matching engine that supports adding domain-specific keywords in real time, enabling flexible expansion of the keyword channel; level identifiers refer to symbols in the logs that represent the log level, such as "E" for Error; and log priority refers to the order of log importance determined by the level identifiers.

[0089] It is understood that the embodiments of this application use keyword channels and level tag channels to filter logs in parallel, thereby obtaining key fault information covering explicit error patterns and high-priority logs, effectively improving the comprehensiveness of log preprocessing and the pertinence of diagnostic input.

[0090] In some embodiments, the target diagnostic task includes user-input prompt text, wherein the prompt text includes at least one of the following: role description text of the large language model, question description text during local knowledge base query, tool description text of the local tool, output format description text of the large language model, role description text of the local tool, and output format description text of the local tool.

[0091] Among them, the prompt text refers to the structured prompt content input to the large language model, which is used to guide it to perform diagnostic tasks; the role description text refers to the definition of the model or tool's identity in the current task; the problem description text refers to the cleaned fault description of the user's original problem, which is used for knowledge base retrieval and model understanding; the tool description text refers to the functional description of the available local tools; and the output format description text refers to the structural requirements for the output of the model or tool.

[0092] It is understood that the embodiments of this application, by introducing structured prompt text containing roles, problems, tools, and output specifications into the target diagnostic task, obtain precise control over the behavior of the large language model, ensuring that it can correctly call tools, retrieve knowledge, and generate diagnostic results according to specifications, thereby improving the accuracy and parsability of the system response.

[0093] Specifically, the role description text is used to help the large language model define its current role according to the tool's needs, allowing it to answer questions more accurately. For example, "You are an Android system problem diagnosis and analysis expert." The problem description text describes the problem according to the tool's needs to obtain the desired results. The output format description text standardizes the output structure according to the tool's needs, so that subsequent automated processing can be performed through code. For example, "Output in JSON format, which should include the following fields: 'name', 'type', and 'result'." Specifically, based on the aforementioned intelligent diagnostic method for vehicle operating systems, such as Figure 5 As shown, the intelligent diagnostic system for vehicle operating systems includes the following modules: data acquisition and processing; knowledge base construction; model fine-tuning; RAG (Retrieval-Augmented Generation) enhanced retrieval; agent decision-making and output, and multi-round interaction. Effective interaction between these modules collectively completes the intelligent diagnostics of the vehicle operating system, improving diagnostic accuracy.

[0094] Furthermore, such as Figure 6 As shown, the specific process for intelligent diagnosis of the vehicle operating system includes the following steps: In step 601, relevant data on operating system fault diagnosis are collected and organized for knowledge base construction and model fine-tuning. The data includes historical diagnostic data, system historical logs, diagnostic rule base, and relevant technical documents.

[0095] In step 602, the relevant historical data is transformed into blocks using an embedded model, specifically the All-MiniLM-L6-v2 model.

[0096] In step 603, a local knowledge base is built using the Chroma vector database to store the vectorized data generated in step 602, supporting knowledge storage, dynamic updates, vector retrieval, etc.

[0097] In step 604, a suitable base language model is selected and the corresponding key is configured to enable the local deployment of its 7B or 13B lightweight version, supporting fast local invocation.

[0098] In step 605, historically accumulated operating system diagnostic data, including log data and corresponding diagnostic results, is cleaned and labeled. The LoRA method is then used to fine-tune the locally deployed lightweight model, and the fine-tuning effect is verified using a test dataset.

[0099] In step 606, for different types of diagnostic tasks for operating system diagnosis, respective intelligent agent workflows are designed to achieve enhanced retrieval based on vector knowledge base.

[0100] In step 607, the prompt word template is designed to integrate the search results into the prompt words and support context management for multi-turn dialogues and CoT (Chain-of-Thought) output.

[0101] In step 608, log data of the vehicle's Android / Linux operating system within a preset time range is collected.

[0102] Specifically, data within a preset time range is obtained from the operating system diagnostic platform via an API interface. The preset time range refers to a time frame determined based on the fault type, used to limit the time window for data collection. Log data refers to the actual log information generated within the operating system.

[0103] In step 609, the collected log data is preprocessed in batches according to different fault / log types.

[0104] In step 610, a hybrid retrieval is performed on the local vector knowledge base based on the collected log information, outputting top-k related knowledge and incorporating it into prompt words, which is then sent to the local large model for decision-making.

[0105] In step 611, the agent's diagnostic results are output, and user feedback is collected and the dialogue continues.

[0106] In step 612, historical diagnostic information of the agent is collected, the correct diagnostic results are vectorized through the Embedding model and stored in the knowledge base.

[0107] The intelligent diagnostic method for vehicle operating systems provided in this application acquires historical diagnostic data of the vehicle operating system, including at least one of historical logs, fault diagnosis results, and a diagnostic rule base. The historical diagnostic data is segmented and vectorized, and a vector database is used to construct and store it in a local knowledge base. Based on this knowledge base, retrieval results are obtained from the current log data. Then, a training dataset is generated based on the fault diagnosis data, and a large language model is fine-tuned. The current log data and the target diagnostic task are input into the fine-tuned large language model. The fine-tuned large language model calls the local knowledge base to execute the diagnostic task and generates fault diagnosis results based on the retrieval results. By fusing historical logs, fault diagnosis results, and the rule base to construct a local knowledge base, and combining this with a retrieval-enhanced fine-tuned large language model to execute the diagnostic task, fault diagnosis results can be automatically and accurately generated, significantly improving accuracy and reducing reliance on manual intervention. This solves the problems in related technologies where vehicle operating system fault diagnosis relies on human experience or fixed rules, cannot dynamically integrate and perform intelligent reasoning, leading to low accuracy.

[0108] Next, referring to the accompanying drawings, we describe the intelligent diagnostic device for an in-vehicle operating system proposed according to an embodiment of this application.

[0109] Figure 7 This is a block diagram of an intelligent diagnostic device for an in-vehicle operating system according to an embodiment of this application.

[0110] like Figure 7 As shown, the vehicle operating system intelligent diagnostic device 10 includes: an acquisition module 100, a construction module 200, and a diagnostic module 300.

[0111] The system comprises the following modules: an acquisition module 100, which acquires historical diagnostic data of the vehicle operating system, including at least one of the vehicle operating system's historical log data, fault diagnosis result data, and a diagnostic rule base; a construction module 200, which performs block-based vectorization transformation on the historical diagnostic data to obtain vectorized data, constructs a local knowledge base using a vector database, stores the vectorized data in the local knowledge base, and retrieves search results from the current log data of the vehicle operating system using the local knowledge base; and a diagnosis module 300, which generates a training dataset based on the fault diagnosis data, fine-tunes the large language model using the dataset, inputs the current log data and the target diagnostic task into the fine-tuned large language model, and the fine-tuned large language model calls the local knowledge base to execute the target diagnostic task, generating fault diagnosis results based on the search results.

[0112] In some embodiments, the construction module 200 is used to: identify knowledge source files in the vector database; parse the knowledge source files and generate string text based on the parsing results; map the string text to a fixed-length vector, adjust the weight of the fixed-length vector according to the field names of the string text, and write the fixed-length vector into the vector database to construct a local knowledge base.

[0113] In some embodiments, the diagnostic module 300 is used to: determine whether a local tool needs to be invoked based on the current log data; if a local tool needs to be invoked, the local tool is used to process the current log data, and the processing result is input into the fine-tuned large language model; if a local tool does not need to be invoked, the local knowledge base is invoked to perform a retrieval action to obtain retrieval results, and a fault diagnosis result is generated based on the retrieval results.

[0114] In some embodiments, the diagnostic module 300 is used to: input current log data into the agent, the agent having a tool list and a prompt word template with function descriptions pre-set within the agent, the agent calling the prompt word template and the tool list, and outputting the calling results of the local tools.

[0115] In some embodiments, the diagnostic module 300 is used to: inject current log data into a prompt word template, the prompt word template outputs a functional description of the current log data, match local tools based on a tool list, the tool list including toolsets, and the toolsets including multiple data pairs of local tools and functional descriptions; if a local tool is matched based on the tool list, it is determined that the local tool needs to be called; if no local tool is matched based on the tool list, it is determined that the local tool does not need to be called.

[0116] In some embodiments, the diagnostic module 300 is used to: extract the format features and semantic features of the current log data; input the format features and semantic features into a log type template, and output the classification result of the current log data from the log type template; perform dual-channel parallel filtering on the classified current log data, delete duplicate logs in the filtered current log data, and perform context association processing on the current log data to obtain a context log cluster.

[0117] In some embodiments, the dual channels include a keyword channel and a level marker channel. The keyword channel includes: constructing a dynamic regular expression engine and using the dynamic regular expression engine to add pre-set domain keywords to the current log data; the level marker channel includes: parsing the level identifier of the current log data, determining the log priority in the current log data based on the level identifier, and extracting logs based on the log priority.

[0118] In some embodiments, the target diagnostic task includes user-input prompt text, wherein the prompt text includes at least one of the following: role description text of the large language model, question description text during local knowledge base query, tool description text of the local tool, output format description text of the large language model, role description text of the local tool, and output format description text of the local tool.

[0119] It should be noted that the foregoing explanation of the embodiment of the intelligent diagnostic method for vehicle operating systems also applies to the intelligent diagnostic device for vehicle operating systems in this embodiment, and will not be repeated here.

[0120] According to the intelligent diagnostic device for vehicle operating systems provided in this application, historical diagnostic data of the vehicle operating system is acquired, including at least one of historical logs, fault diagnosis results, and a diagnostic rule base. The historical diagnostic data is segmented and vectorized, and a local knowledge base is constructed and stored using a vector database. Based on this knowledge base, the current log data is retrieved to obtain search results. Then, a training dataset is generated based on the fault diagnosis data, and a large language model is fine-tuned. The current log data and the target diagnostic task are input into the fine-tuned large language model. The fine-tuned large language model calls the local knowledge base to execute the diagnostic task and generates fault diagnosis results based on the search results. By fusing historical logs, fault diagnosis results, and the rule base to construct a local knowledge base, and combining this with a retrieval-enhanced fine-tuned large language model to execute the diagnostic task, fault diagnosis results can be automatically and accurately generated, significantly improving accuracy and reducing reliance on manual intervention. This solves the problems in related technologies where vehicle operating system fault diagnosis relies on human experience or fixed rules, cannot dynamically integrate and perform intelligent reasoning, leading to low accuracy.

[0121] Figure 8 A schematic diagram of the structure of a vehicle provided in an embodiment of this application. The vehicle may include: The memory 801, the processor 802, and the computer program stored on the memory 801 and capable of running on the processor 802.

[0122] When the processor 802 executes the program, it implements the intelligent diagnostic method for the vehicle operating system provided in the above embodiments.

[0123] Furthermore, the vehicle also includes: Communication interface 803 is used for communication between memory 801 and processor 802.

[0124] The memory 801 is used to store computer programs that can run on the processor 802.

[0125] The memory 801 may include high-speed RAM (Random Access Memory) memory, and may also include non-volatile memory, such as at least one disk storage.

[0126] If the memory 801, processor 802, and communication interface 803 are implemented independently, then the communication interface 803, memory 801, and processor 802 can be interconnected via a bus to complete communication between them. The bus can be an ISA (Industry Standard Architecture) bus, a PCI (Peripheral Component Interconnect) bus, or an EISA (Extended Industry Standard Architecture) bus, etc. The bus can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 8 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0127] Optionally, in a specific implementation, if the memory 801, processor 802, and communication interface 803 are integrated on a single chip, then the memory 801, processor 802, and communication interface 803 can communicate with each other through an internal interface.

[0128] The processor 802 may be a CPU (Central Processing Unit), an ASIC (Application Specific Integrated Circuit), or one or more integrated circuits configured to implement the embodiments of this application.

[0129] In the description of this specification, the references to terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., refer to specific features, structures, materials, or characteristics described in connection with that embodiment or example, which are included in at least one embodiment or example of this application. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification, as well as the features of different embodiments or examples.

[0130] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one of that feature. In the description of this application, "N" means at least two, such as two, three, etc., unless otherwise explicitly specified.

[0131] Any process or method described in the flowchart or otherwise herein can be understood as representing a module, segment, or portion of code comprising one or N executable instructions for implementing custom logic functions or processes, and the scope of the preferred embodiments of this application includes additional implementations in which functions may be performed not in the order shown or discussed, including substantially simultaneously or in reverse order depending on the functions involved, as should be understood by those skilled in the art to which embodiments of this application pertain.

[0132] It should be understood that various parts of this application can be implemented using hardware, software, firmware, or a combination thereof. In the above embodiments, steps or methods can be implemented using software or firmware stored in memory and executed by a suitable instruction execution system. For example, if implemented in hardware, as in another embodiment, it can be implemented using any of the following techniques known in the art, or a combination thereof: discrete logic circuits having logic gates for implementing logical functions on data signals, application-specific integrated circuits (ASICs) having suitable combinational logic gates, programmable gate arrays (FPGAs), field-programmable gate arrays (FPGAs), etc.

[0133] Those skilled in the art will understand that all or part of the steps of the methods implementing the above embodiments can be implemented by a program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, the program includes one or a combination of the steps of the method embodiments.

[0134] Although embodiments of this application have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting this application. Those skilled in the art can make changes, modifications, substitutions and variations to the above embodiments within the scope of this application.

Claims

1. A method for intelligent diagnosis of an in-vehicle operating system, characterized in that, Includes the following steps: Obtain historical diagnostic data of the vehicle operating system, wherein the historical diagnostic data includes at least one of the historical log data, fault diagnosis result data, and diagnostic rule base of the vehicle operating system; The historical diagnostic data is divided into blocks and vectorized to obtain vectorized data. A local knowledge base is constructed using a vector database. The vectorized data is stored in the local knowledge base. The current log data of the vehicle operating system is retrieved using the local knowledge base to obtain retrieval results. A training dataset is generated based on the fault diagnosis data. The large language model is then fine-tuned using the dataset. The current log data and the target diagnosis task are input into the fine-tuned large language model. The fine-tuned large language model calls the local knowledge base to execute the target diagnosis task and generates fault diagnosis results based on the retrieval results.

2. The intelligent diagnostic method for vehicle operating systems according to claim 1, characterized in that, The construction of a local knowledge base using a vector database includes: Identify the knowledge source files in the vector database; The knowledge source file is parsed, and a string text is generated based on the parsing results; The string text is mapped to a fixed-length vector, the weight of the fixed-length vector is adjusted according to the field name of the string text, and the fixed-length vector is written into a vector database to build a local knowledge base.

3. The intelligent diagnostic method for vehicle operating systems according to claim 1, characterized in that, The diagnostic process for the fine-tuned large language model includes: Determine whether local tools need to be invoked based on the current log data; If it is necessary to call local tools, then use the local tools to process the current log data and input the processing result into the fine-tuned large language model; If the current log data does not require calling local tools, then the local knowledge base is invoked to perform a search action to obtain search results, and the fault diagnosis results are generated based on the search results.

4. The intelligent diagnostic method for vehicle operating systems according to claim 3, characterized in that, The step of determining whether to invoke local tools based on the current log data includes: The current log data is input into the agent, which has a pre-set tool list and function description prompt templates. The agent calls the prompt templates and tool list and outputs the call results of the local tools.

5. The intelligent diagnostic method for vehicle operating systems according to claim 4, characterized in that, The processing flow of the intelligent agent includes: The current log data is injected into the prompt word template, the prompt word template outputs a functional description of the current log data, and local tools are matched based on the tool list, the tool list includes a toolset, and the toolset includes multiple data pairs of the local tools and the functional description; If the local tool is matched based on the tool list, it is determined that the local tool needs to be invoked; otherwise, it is determined that the local tool does not need to be invoked.

6. The intelligent diagnostic method for vehicle operating systems according to claim 3, characterized in that, The process of using the local tool to process the current log data includes: Extract the format and semantic features of the current log data; The format features and semantic features are input into the log type template, and the log type template outputs the classification result of the current log data; The current log data that has been classified is filtered in parallel through two channels to remove duplicate logs from the filtered current log data, and the current log data is then processed with context association to obtain a context log cluster.

7. The intelligent diagnostic method for vehicle operating systems according to claim 6, characterized in that, The dual channels include a keyword channel and a ranking label channel, wherein, The keyword channel includes: constructing a dynamic regular expression engine, and using the dynamic regular expression engine to add pre-set domain keywords to the current log data; The level marking channel: parses the current log data level identifier, determines the log priority in the current log data based on the level identifier, and extracts logs based on the log priority.

8. The intelligent diagnostic method for vehicle operating systems according to claim 1, characterized in that, The target diagnostic task includes user-input prompt text, wherein the prompt text includes at least one of the role description text of the large language model, the problem description text during the local knowledge base query, the tool description text of the local tool, the output format description text of the large language model, the role description text of the local tool, and the output format description text of the local tool.

9. An intelligent diagnostic device for an in-vehicle operating system, characterized in that, include: The acquisition module is used to acquire historical diagnostic data of the vehicle operating system, wherein the historical diagnostic data includes at least one of the historical log data, fault diagnosis result data, and diagnostic rule base of the vehicle operating system; The module is used to perform block-based vectorization transformation on the historical diagnostic data to obtain vectorized data, build a local knowledge base using a vector database, store the vectorized data using the local knowledge base, and retrieve the current log data of the vehicle operating system using the local knowledge base to obtain retrieval results. The diagnostic module is used to generate a training dataset based on the fault diagnosis data, fine-tune the large language model using the dataset, input the current log data and the target diagnostic task into the fine-tuned large language model, and the fine-tuned large language model calls the local knowledge base to execute the target diagnostic task and generates fault diagnosis results based on the retrieval results.

10. A vehicle, characterized in that, include: A memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the intelligent diagnostic method for an in-vehicle operating system as described in any one of claims 1-8.

Images