Vehicle diagnosis method and device based on information interaction, electronic equipment and medium

Abstract

The application relates to the technical field of vehicle diagnosis, and discloses a vehicle diagnosis method and device based on information interaction, electronic equipment and a medium, wherein the method comprises the following steps: obtaining vehicle diagnosis data and judging an exception, automatically performing split-screen processing when the exception is detected, directly inputting a natural language diagnosis question in a second display area by a user, performing intention recognition and entity extraction by the system, not needing the user to learn professional terms or remember menu paths, significantly reducing an operation threshold, then performing fault analysis based on to-be-diagnosed information and diagnosis data, generating a diagnosis analysis result, automatically performing positioning, highlighting or expansion operations on related items in the first display area according to the analysis result, and directly mapping the analysis conclusion to specific related items. The application has the beneficial effect that the cumbersome process of manual searching and switching interfaces by the user is avoided, and the fault troubleshooting efficiency is improved.

Description

Technical Field

[0001] This invention relates to the field of vehicle diagnostic technology, and in particular to a vehicle diagnostic method, device, electronic device, and medium based on information interaction. Background Technology

[0002] Traditional vehicle diagnostic methods typically rely on manual operation of diagnostic equipment by the user, navigating through menus to view fault codes, data streams, and other information. Users need a certain level of expertise to understand the meaning of fault codes and the hierarchical relationships between various control modules. When the diagnostic equipment reads fault codes or other abnormal data, the system passively displays a list of values, requiring the user to manually navigate between multiple interfaces to find relevant information and then rely on their own experience to determine the cause of the fault. This lack of proactive guidance makes it difficult for non-professionals to diagnose the problem independently. Summary of the Invention

[0003] Therefore, it is necessary to propose a vehicle diagnostic method, device, electronic equipment, and medium based on information interaction to address the existing vehicle diagnostic problems based on information interaction.

[0004] A vehicle diagnostic method based on information interaction, the method comprising: Acquire vehicle diagnostic data, which includes at least one of system information, fault codes, real-time data streams, and control unit status information; Determine whether there is abnormal information in the diagnostic data. If there is abnormal information, perform screen splitting on a preset screen to obtain a first display area and a second display area. The first display area displays the diagnostic interface, and the second display area provides an interactive interface. The second display area receives natural language diagnostic questions input by the user. The natural language diagnostic problem is subjected to intent recognition and entity extraction to obtain the information to be diagnosed; Based on the information to be diagnosed and the diagnostic data, a fault analysis is performed to generate diagnostic analysis results; Based on the diagnostic analysis results, perform corresponding operations on the relevant items in the diagnostic interface displayed in the first display area.

[0005] Furthermore, the step of performing fault analysis based on the information to be diagnosed and the diagnostic information to generate diagnostic analysis results includes: Obtain user operation information for the first display area; Based on the operation information, obtain the context display information of the first display area; Based on the operation information, the context display information, the information to be diagnosed, and the diagnostic data, fault analysis is performed to generate diagnostic analysis results.

[0006] Further, the step of performing fault analysis based on the operation information, the context display information, the information to be diagnosed, and the diagnostic data to generate diagnostic analysis results includes: The operation information is converted into a first semantic vector, the context display information is converted into a second semantic vector, the information to be diagnosed is converted into a third semantic vector, and the diagnostic data is converted into a fourth semantic vector. The first semantic vector, the second semantic vector, the third semantic vector, and the fourth semantic vector are concatenated and then input into a pre-trained fault reasoning model to obtain the fault reasoning model outputs diagnostic analysis results and linkage operation instructions; wherein, the linkage operation instructions are used to instruct the corresponding operation to be performed on the relevant items in the first display area.

[0007] Furthermore, the step of performing fault analysis based on the information to be diagnosed and the diagnostic data to generate diagnostic analysis results includes: When multiple fault codes exist in the diagnostic data, the semantic correlation between each fault code and the information to be diagnosed is calculated separately. Based on the semantic relevance, the preset severity level of each fault code, and the system impact range associated with each fault code, a priority ranking list for troubleshooting the multiple fault codes is generated. The priority list for investigation is included as part of the diagnostic analysis results.

[0008] Further, the step of performing corresponding operations on relevant items in the diagnostic interface displayed in the first display area based on the diagnostic analysis results includes: The priority sorting list for the investigation is displayed in the second display area; In response to the user's selection of a fault code in the sorted list, the system scrolls to the location of the fault code in the first display area and expands the corresponding sub-information window; wherein the sub-information window contains a description of the fault code, possible causes of the fault, and links to preset repair steps.

[0009] Furthermore, after the step of performing corresponding operations on relevant items in the diagnostic interface displayed in the first display area based on the diagnostic analysis results, the method further includes: Save the natural language diagnostic questions and their corresponding intent recognition results received each time through the second display area to form a dialogue history; The second display area is used to determine whether a new natural language diagnostic question has been received. If a new natural language diagnostic question is received through the second display area, the dialogue history and the current question are input together for intent recognition and entity extraction to obtain new diagnostic information; Based on the new information to be diagnosed and the diagnostic data, fault analysis is performed to generate new diagnostic analysis results. Based on the new diagnostic analysis results, perform corresponding operations on the relevant items in the diagnostic interface displayed in the first display area.

[0010] Furthermore, the step of performing fault analysis based on the information to be diagnosed and the diagnostic data to generate diagnostic analysis results includes: Continuously collect real-time data streams of vehicles and monitor whether the values ​​of each data item in the real-time data stream exceed the corresponding preset thresholds; If the value of a certain data item exceeds its preset threshold, the data item is marked as an abnormal data item, and the abnormal data item and the extent to which it exceeds the threshold are included as part of the diagnostic data. The abnormal data items are associated and matched with the fault codes in the diagnostic data; If the correlation between a fault code and at least one abnormal data item exceeds a preset threshold, a description of the causal relationship between the fault code and the abnormal data item will be output in the diagnostic analysis results.

[0011] A vehicle diagnostic device based on information interaction, the device comprising: The acquisition module is used to acquire vehicle diagnostic data, which includes at least one of system information, fault codes, real-time data streams, and control unit status information. The first judgment module is used to determine whether there is abnormal information in the diagnostic data. If there is abnormal information, the screen is split on a preset screen to obtain a first display area and a second display area. The first display area displays the diagnostic interface, and the second display area provides an interactive interface. The first receiving module is used to receive natural language diagnostic questions input by the user through the second display area; The extraction module is used to perform intent recognition and entity extraction on the natural language diagnostic question to obtain the information to be diagnosed; The first generation module is used to perform fault analysis based on the information to be diagnosed and the diagnostic data, and generate diagnostic analysis results. The first execution module is used to perform corresponding operations on the relevant items in the diagnostic interface displayed in the first display area based on the diagnostic analysis results.

[0012] An electronic device includes a memory and a processor, the memory storing a computer program that, when executed by the processor, causes the processor to perform the following steps: Acquire vehicle diagnostic data, which includes at least one of system information, fault codes, real-time data streams, and control unit status information; Determine whether there is abnormal information in the diagnostic data. If there is abnormal information, perform screen splitting on a preset screen to obtain a first display area and a second display area. The first display area displays the diagnostic interface, and the second display area provides an interactive interface. The second display area receives natural language diagnostic questions input by the user. The natural language diagnostic problem is subjected to intent recognition and entity extraction to obtain the information to be diagnosed; Based on the information to be diagnosed and the diagnostic data, a fault analysis is performed to generate diagnostic analysis results; Based on the diagnostic analysis results, perform corresponding operations on the relevant items in the diagnostic interface displayed in the first display area.

[0013] A computer-readable storage medium storing a computer program, which, when executed by a processor, causes the processor to perform the following steps: Acquire vehicle diagnostic data, which includes at least one of system information, fault codes, real-time data streams, and control unit status information; Determine whether there is abnormal information in the diagnostic data. If there is abnormal information, perform screen splitting on a preset screen to obtain a first display area and a second display area. The first display area displays the diagnostic interface, and the second display area provides an interactive interface. The second display area receives natural language diagnostic questions input by the user. The natural language diagnostic problem is subjected to intent recognition and entity extraction to obtain the information to be diagnosed; Based on the information to be diagnosed and the diagnostic data, a fault analysis is performed to generate diagnostic analysis results; Based on the diagnostic analysis results, perform corresponding operations on the relevant items in the diagnostic interface displayed in the first display area.

[0014] The beneficial effects of this invention are as follows: By acquiring vehicle diagnostic data and identifying anomalies, the system automatically performs split-screen processing when an anomaly is detected. Users can directly input natural language diagnostic questions in the second display area, and the system performs intent recognition and entity extraction. Users do not need to learn professional terminology or memorize menu paths, which significantly reduces the operational threshold. Then, based on the information to be diagnosed and the diagnostic data, the system performs fault analysis and generates diagnostic analysis results. According to the analysis results, the system automatically performs operations such as locating, highlighting, or expanding the relevant items in the first display area, directly mapping the analysis conclusions to specific relevant items. This avoids the tedious process of users manually searching and switching interfaces, and improves the efficiency of fault diagnosis. Attached Figure Description

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

[0016] in: Figure 1 This is a diagram illustrating the application environment of a vehicle diagnostic method based on information interaction in one embodiment. Figure 2 This is a flowchart of a vehicle diagnostic method based on information interaction in one embodiment; Figure 3 This is a structural block diagram of a vehicle diagnostic device based on information interaction in one embodiment; Figure 4 This is a structural block diagram of an electronic device in one embodiment. Detailed Implementation

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

[0018] Figure 1 This is a diagram illustrating a vehicle diagnostic application environment based on information interaction in one embodiment. (Refer to...) Figure 1This information-interaction-based vehicle diagnostic method is applied to an information-interaction-based vehicle diagnostic system. The system includes a vehicle terminal 110 and a server 120. The vehicle terminal 110 and server 120 are connected via a network. The vehicle terminal 110 can be a desktop terminal or a mobile terminal; the mobile terminal can be at least one of a mobile phone, tablet, or laptop. The server 120 can be a standalone server or a server cluster consisting of multiple servers. The vehicle terminal 110 is used to acquire vehicle diagnostic data, and the server 120 is used to generate diagnostic analysis results.

[0019] like Figure 2 As shown, in one embodiment, a vehicle diagnostic method based on information interaction is provided. This method can be applied to either a terminal or a server; this embodiment is illustrated using a terminal as an example. The vehicle diagnostic method based on information interaction specifically includes the following steps: S1: Obtain vehicle diagnostic data, which includes at least one of system information, fault codes, real-time data streams, and control unit status information; S2: Determine whether there is abnormal information in the diagnostic data. If there is abnormal information, perform screen splitting on a preset screen to obtain a first display area and a second display area. The first display area displays the diagnostic interface, and the second display area provides an interactive interface. S3: Receive natural language diagnostic questions input by the user through the second display area; S4: Perform intent recognition and entity extraction on the natural language diagnostic problem to obtain the information to be diagnosed; S5: Perform fault analysis based on the information to be diagnosed and the diagnostic data, and generate diagnostic analysis results; S6: Based on the diagnostic analysis results, perform corresponding operations on the relevant items in the diagnostic interface displayed in the first display area.

[0020] As described in step S1 above, vehicle diagnostic data is acquired. This diagnostic data includes at least one of the following: system information, fault codes, real-time data streams, and control unit status information. System information includes, for example, the VIN (Vehicle Identification Number) and ECU (Electronic Control Unit); fault codes (DTCs) include current and historical fault codes; real-time data streams include engine speed, oxygen sensor voltage, and coolant temperature; control unit status information refers to the operating mode and communication status of each ECU. The terminal connects to the vehicle diagnostic interface via wired or wireless means and sends standardized requests to acquire data. For example, a diagnostic tablet computer connects to a 2023 new energy vehicle and reads: "System Information: BMS Version V2.1", "Fault Code: P0A0F - Motor System Overheating", "Real-time Data Stream: Motor Temperature 98℃ (Threshold 90℃)", and "Control Unit Status: VCU (Vehicle Control Unit) communication is normal, MCU (Motor Control Unit) response is delayed". This raw data is stored as a structured data packet for subsequent analysis.

[0021] As described in step S2 above, it is determined whether there is abnormal information in the diagnostic data. If there is abnormal information, the screen is split into a first display area and a second display area on a preset screen. The first display area displays the diagnostic interface, and the second display area provides an interactive interface. When an abnormality is detected, the screen is automatically and dynamically split instead of manually switching interfaces, thus ensuring that diagnosis and interaction can proceed in parallel. The first area retains the original diagnostic interface, and the second area displays the interactive interface. For example, suppose the diagnostic system detects a motor temperature of 98℃ (threshold 90℃) and determines it to be abnormal. At this time, a 12-inch touchscreen is vertically divided: the left 70% area (first area) continuously displays a real-time data stream waveform and highlights the motor temperature parameter in red; the right 30% area (second area) displays a natural language interactive window, prompting "Please describe the problem you encountered".

[0022] As described in step S3 above, the second display area receives natural language diagnostic questions input by the user. Users can ask questions in the second area via text input or speech-to-text input, such as "What other faults can motor overheating cause?" or "Why does the P0A0F fault code reappear when the vehicle speed exceeds 60km / h?", supporting multi-turn dialogue context memory. The second area integrates a voice acquisition module and a natural language processing front-end to perform noise reduction, word segmentation, and preliminary formatting of the input. For example, a technician can type "Is this P0A0F fault code caused by insufficient coolant?" into the text box in the second area. Simultaneously, the microphone icon allows long-press voice input: "Please help me analyze the relationship between motor temperature and output torque in the data stream," encapsulating the original text or speech-to-text input into a request message.

[0023] As described in step S4 above, intent recognition and entity extraction are performed on the natural language diagnostic question to obtain the information to be diagnosed. Intent recognition is used to classify user purposes, such as "fault cause analysis", "data association query", "repair procedure guidance", "parameter comparison", etc.; entity extraction extracts key objects from the question, such as fault codes (P0A0F), components, data items, and conditions. For example, if a user inputs "Why doesn't the cooling fan turn when the motor temperature is 98℃?", the intent recognition result is "cause and effect analysis", and the entity extraction results are: component = [motor, cooling fan], parameter = [motor temperature = 98℃], action = [not turning], thus generating the information to be diagnosed: a structured query containing "fault phenomenon: motor is hot and the fan is not started; associated data: the fan control circuit, PWM (Pulse Width Modulation) signal, and VCU command need to be checked". For another example, "compare the oxygen sensor waveforms of today and yesterday", the intent is "data comparison", and the entity is [oxygen sensor waveform, time window = today / yesterday].

[0024] As described in step S5 above, fault analysis is performed based on the information to be diagnosed and the diagnostic data to generate diagnostic analysis results. Analysis methods may include rule-based expert systems, machine learning classifiers, or generative models outputting explanatory text. The analysis results should include possible causes, probabilities, recommended checks, and repair suggestions. For example, if the information to be diagnosed is "motor temperature 98℃ and cooling fan not turning," the system, combining real-time data stream (fan duty cycle = 0%, motor controller no fan feedback signal) and control unit status (VCU issues fan start command, but MCU (Motor Control Unit) does not execute), generates the following diagnostic analysis result: "Root cause: MCU internal drive stage open circuit or fan relay stuck; confidence level 85%; recommended action: measure MCU fan pin voltage; if it is 0V, replace the MCU driver board; if it is 12V, check the fan motor." This result is accompanied by a corresponding repair circuit diagram or diagnostic step link.

[0025] Although vehicle diagnostic data (fault codes, data streams, etc.) has been acquired and the user's natural language questions (intent and entity) have been understood, a significant semantic gap still exists between these two types of information. Diagnostic data represents low-level, numerical, and coded signals, while user questions are high-level semantic descriptions of phenomena. Traditional methods can only perform simple rule matching (e.g., mapping "engine vibration" to fault code P0300). When a vehicle has multiple associated fault codes, the data stream exhibits complex coupling anomalies, or the user question is ambiguous (e.g., "Why are the brake lights not working?" but there is no directly corresponding fault code), conventional programs cannot autonomously plan reasoning paths, actively call external knowledge bases for verification, or form interpretable conclusions after multiple steps of reasoning. Specifically, this can be achieved using a Diagnostic Reasoning Agent driven by a large language model. This agent is an autonomous reasoning system with capabilities for autonomous planning, tool invocation, memory maintenance, and comprehensive judgment. It uses the large language model as its core decision-making brain, equipped with multiple external tool interfaces such as knowledge graph query, maintenance manual retrieval, data flow analysis, and historical work order matching, and endowed with multi-step iterative reasoning capabilities. After receiving the information to be diagnosed and the diagnostic data, the agent autonomously formulates a reasoning plan, invokes tools as needed to obtain supplementary evidence, and, when necessary, proactively asks the user follow-up questions or requests action tests through a second display area. Finally, it synthesizes all the evidence chains to generate a structured diagnostic analysis result containing root cause conclusions, investigation priorities, and linked operation instructions.

[0026] Specifically, the agent's perception module receives the output diagnostic information (intent labels and entity lists) and all diagnostic data (fault code details, real-time data stream values, and system status indicators), integrates all information into a unified problem context text, and stores it in the short-term memory of the memory module. The agent's planner generates an initial diagnostic reasoning plan based on the problem context. This plan is a series of parallel or sequential sub-tasks, such as simultaneously initiating three sub-tasks: "querying fault code definitions," "comparing data stream thresholds," and "retrieving historical similar cases," and setting tool invocation parameters for each sub-task. The agent's executor concurrently or sequentially invokes external tools based on the sub-task list generated by the planner. These tools include: a knowledge graph query tool (to obtain the relationships between fault codes and component topology), a maintenance manual retrieval tool (to match standard inspection procedures), a data stream analysis tool (to calculate the deviation and trend between real-time data and standard values), and a historical work order matching tool (to recall the processing conclusions of similar cases). The results returned by each tool are stored as evidence in the memory module. The planner synthesizes the evidence returned by the first round of tools and makes preliminary hypotheses. If the evidence is insufficient to support a definitive conclusion (e.g., abnormal data flow but it cannot be confirmed whether the problem lies with the sensor itself or the wiring), the planner generates a new verification subtask—issuing a clear operation request to the user through the second display area (e.g., "Please click the oil pressure sensor action test button in the first display area"), and waits for the user's feedback data after execution as a new round of evidence input. Once sufficient evidence is available, the agent's summator performs a weighted synthesis of all evidence chains, sorting them according to "most likely cause > second most likely cause > cause to be ruled out," and generates a diagnostic analysis result. The core components of the intelligent agent include the following five modules: a planner, implemented based on a large language model, responsible for decomposing complex problems into a sequence of executable sub-tasks and dynamically adjusting the reasoning path based on intermediate results; an executor, responsible for calling various external tool APIs according to the planner's instructions and processing the returned results; a memory module, containing short-term memory (the execution record of the sub-tasks in the current round and intermediate conclusions) and long-term memory (dialogue history and diagnostic conclusions from previous rounds), ensuring the coherence of multi-step reasoning; a toolset, namely the aforementioned external interfaces such as knowledge graph query, maintenance manual retrieval, data flow analysis, and historical work order matching; and a summarizer, which, after all tools have been called, comprehensively evaluates all evidence and generates the final structured diagnostic analysis results.

[0027] The construction method of this intelligent agent consists of four steps: First, select an open-source basic large model (such as Qwen-72B or DeepSeek-V3) as the base for the planner and summator; Second, develop using the ReAct or Plan-and-Solve intelligent agent framework, and use a small number of chain-of-thought prompts to teach the large model an iterative reasoning pattern of "thinking → acting → observing"; Third, define standardized input and output interfaces for each external tool (e.g., a knowledge graph query tool receives fault code numbers and returns a list of related components and signal topology relationships), and complete registration in the agent's tool registry; Fourth, perform instruction fine-tuning or in-context learning on a labeled diagnostic reasoning dataset to familiarize the agent with the sub-task decomposition methods and tool calling habits in diagnostic scenarios, ultimately forming a deployable inference engine.

[0028] As described in step S6 above, based on the diagnostic analysis results, corresponding operations are performed on the relevant items in the diagnostic interface displayed in the first display area. These operations include, but are not limited to: automatically highlighting or selecting relevant fault codes, marking abnormal moments on the data stream curve, popping up associated circuit diagrams, initiating specific actuator tests, or generating repair work orders. The aforementioned 'relevant items' specifically refer to one or more elements in the content displayed in the first display area determined based on the diagnostic analysis results, including but not limited to fault code entries, real-time data stream parameter items, circuit diagram nodes, and ECU menu items. 'corresponding operations' include, but are not limited to, performing one or more of the following operations on the elements: visual highlighting, automatically locating and scrolling to the element, expanding its collapsed or detailed sub-information window, and popping up a contextual association diagram or repair guidance link. For example: If the previous analysis indicates an "open circuit in the fan drive stage", the following operations will be automatically performed in the diagnostic interface of the first area: ① Change the background color of the fault code P0A0F entry to red and make it flash; ② Mark the "fan duty cycle" parameter in the real-time data stream and overlay a trend prediction line; ③ Pop up a floating button "Execute Fan Relay Test", and after clicking, send the UDS (Unified Diagnostic Services) diagnostic service 0x2E write test command; ④ If there is a circuit diagram tree control in the interface, automatically expand the "Cooling System / Fan Control" node and scale it to the relevant pins.

[0029] To further improve the accuracy of diagnostic analysis and the naturalness of interaction, the optimized implementation of the present invention can further integrate the user's real-time operations on the diagnostic interface and the currently displayed context information. The optimization process will be described in detail below with reference to examples.

[0030] In one embodiment, step S5, which involves performing fault analysis based on the information to be diagnosed and the diagnostic information to generate diagnostic analysis results, includes: S501: Obtain user operation information on the first display area; S502: Obtain the context display information of the first display area based on the operation information; S503: Based on the operation information, the context display information, the information to be diagnosed, and the diagnostic data, perform fault analysis and generate diagnostic analysis results.

[0031] As described in step S501 above, acquiring user operation information on the first display area aims to capture the user's active operation behavior on the diagnostic interface, such as clicks, swipes, selection, zooming, long presses, dragging, and other interactive events. This operation information reflects the user's focus or additional intervention in the data during the current diagnostic process. For example, the user may manually select a fault code, zoom in on a segment of the data stream waveform, or click on the property window of an ECU node. For example, in the first display area of ​​the tablet computer, the technician sees the "oxygen sensor voltage" fluctuating between 0.1V and 0.9V in the real-time data stream curve, but there is a period of 5 seconds where it remains unchanged at 0.45V. The technician selects this abnormal time period with their finger, and the "selection operation" is captured by the touch event listener. The operation type is recorded as "area selection", the timestamp corresponding to the operation coordinate range is T1 to T2, and the operation object is "oxygen sensor voltage data stream".

[0032] As described in step S502 above, context display information of the first display area is obtained based on the operation information. According to the user operation information captured in S501, context display content related to the operation is extracted from the first display area. Context display information refers to the specific form and state of the diagnostic data presented on the screen when the operation occurs. It refers to the set of states of the content currently presented on the interface when the user operates the first display area, including but not limited to highlighted items, screen scroll position, expanded data items and their values. Examples include frozen frame data associated with a clicked fault code, the numerical range and trend of the selected data segment, detailed parameters of the control unit displayed by the hovered icon, and a portion of the ECU topology visible at the current display resolution and zoom level. For example, following the selection operation in S501, the system obtains the specific numerical sequence of the "oxygen sensor voltage data stream" within the time period T1 to T2: [0.45V, 0.45V, 0.45V, 0.45V, 0.45V]. Simultaneously, it obtains other related contextual display information within this time period: the engine speed is displayed as stable at 2000 rpm, the air-fuel ratio is displayed as 14.7:1, and the injection pulse width is displayed as 3.2 ms. Additionally, a small window displaying "Oxygen Sensor Heater Status" is opened on the right side of the current first display area, showing "Heater Duty Cycle = 0%". This contextual display information, along with the operation information, is packaged into a structured context object.

[0033] As described in step S503 above, fault analysis is performed based on the operation information, the context display information, the information to be diagnosed, and the diagnostic data to generate a diagnostic analysis result. It inputs the user's operation intent from S501, the screen context from S502, the natural language information to be diagnosed obtained from S4, and the raw diagnostic data acquired from S1 into the fault analysis engine. The analysis engine can use rule-based reasoning, decision trees, or large language models to generate more targeted and accurate diagnostic analysis results. Integrating operation information and context display information avoids misjudgments caused by ambiguous natural language expressions from the user and utilizes visual cues actively provided by the user for precise location analysis. For example, if a user's natural language question is "Why does the oxygen sensor voltage remain unchanged?", and S501 captures the user's selection action, S502 shows that the oxygen sensor voltage remains constant at 0.45V and the heater duty cycle is 0% during the selected time period, and the diagnostic data in S1 includes "Fault code P0135 (Oxygen sensor heater circuit failure)", the overall judgment is that the specific time period the user is concerned about is precisely the sensor inertia zone caused by heater failure, rather than the entire operating cycle. The final diagnostic analysis result is: "The root cause of the fault is an open circuit in the oxygen sensor heater power supply line (Fault code P0135), causing the sensor to be unable to enter closed-loop control under idling conditions, and the output voltage is clamped at 0.45V by the internal reference circuit; it is recommended to check the sensor heating pin voltage and related fuses." This result has higher spatiotemporal resolution and operational relevance compared to results generated solely based on natural language or diagnostic data.

[0034] In one embodiment, step S503, which involves performing fault analysis based on the operation information, the context display information, the information to be diagnosed, and the diagnostic data to generate diagnostic analysis results, includes: S5031: Convert the operation information into a first semantic vector, convert the context display information into a second semantic vector, convert the information to be diagnosed into a third semantic vector, and convert the diagnostic data into a fourth semantic vector; S5032: The first semantic vector, the second semantic vector, the third semantic vector, and the fourth semantic vector are concatenated and input into the pre-trained fault reasoning model to obtain the fault reasoning model outputs diagnostic analysis results and linkage operation instructions; wherein, the linkage operation instructions are used to instruct the relevant items in the first display area to perform corresponding operations.

[0035] Among them, the fault reasoning model adopts a Transformer-based Encoder-Decoder architecture. The Encoder part uses a pre-trained Chinese or English BERT model to separately encode four types of input information into semantic vectors of fixed dimensions: operation information (such as which fault code the user clicked), context display information (the list of currently visible interface elements in the first display area), information to be diagnosed (key entities extracted after intent recognition of the user's natural language question), and diagnostic data (vehicle fault codes, abnormal data flow, etc.). After the text sequences of the four types of information are respectively encoded by BERT, the global representation vector at the first position is taken and spliced to form a joint vector fused with multi-source information. The Decoder part adopts a six-layer Transformer decoder to generate output word by word in an autoregressive manner; the decoder performs cross-attention on the fused vector output by the Encoder in each layer, so as to ensure that the generated diagnosis conclusion and operation instruction are highly aligned with the current input state.

[0036] The training data of the fault reasoning model can be sourced from actual vehicle diagnosis session records, and manually annotated by automobile maintenance experts. The input side of each training sample includes four fields: the user's operation information (a sequence of actions described in natural language, such as "click fault code P0521"), the screen content of the current left diagnosis interface (the list of visible fault codes and highlighted items obtained through interface screenshot and OCR recognition), the structured information to be diagnosed obtained after intent recognition of the natural language question raised by the user (such as "why the brake light does not light up"), and the real diagnostic data collected through the OBD interface (including the list of fault codes and abnormal items exceeding the threshold in the data flow). The output side is annotated by experts with two parts of content: a diagnosis analysis result in natural language form, and a set of specific linkage operation instructions, for example, "scroll to the row where fault code P0521 is located, highlight the row, expand its sub-information window".

[0037] The fault reasoning model is trained by an end-to-end supervised learning method, and the loss function is a multi-task joint loss, where the cross-entropy loss is used for the natural language generation part, and the cross-entropy loss is also used for the linkage operation instruction part (if the instruction is regarded as a sequence generation task) or the weighted sum of the classification loss and the pointer network loss. In the experiment, more emphasis is placed on improving the accuracy of the operation instructions. AdamW is selected as the optimizer, and a cosine annealing strategy after learning rate warm-up is adopted.

[0038] As described in step S5031 above, the operation information is converted into a first semantic vector, the context display information is converted into a second semantic vector, the information to be diagnosed is converted into a third semantic vector, and the diagnostic data is converted into a fourth semantic vector. Multi-source heterogeneous information is uniformly mapped to a high-dimensional semantic vector space for subsequent fusion processing by a deep learning model. The operation information is typically a non-text signal and requires an encoder to obtain the first semantic vector; the context display information can be converted into a second semantic vector through temporal encoding or feature extraction; the information to be diagnosed can be used to extract the third semantic vector using a pre-trained language model (such as a bidirectional encoder representation transformer); and the diagnostic data can be structured and encoded into a fourth semantic vector. Semantic vectors refer to the conversion of information such as operations, text, and data into fixed-dimensional numerical vectors with semantic representation through word embedding or text encoding techniques. For example, when a user selects a segment of the oxygen sensor voltage that is constant, the operation information type is "selection," and the coordinates correspond to a time window, resulting in the first semantic vector [0.12, -0.35, ...]. The contextual information displayed includes the voltage value during that period [0.45, 0.45, ...] and the heater duty cycle of 0%, forming the second semantic vector [0.78, 0.01, ...]. The natural language question "Why is the oxygen sensor voltage unchanged?" is processed by BERT to obtain the third semantic vector [-0.22, 0.43, ...]. The fault code P0135 and the data stream speed in the diagnostic data are encoded to obtain the fourth semantic vector [0.56, -0.11, ...]. These four vectors are extracted separately, maintaining the semantic integrity of their respective modalities.

[0039] As described in step S5032 above, the first semantic vector, the second semantic vector, the third semantic vector, and the fourth semantic vector are concatenated and input into the pre-trained fault reasoning model to obtain the diagnostic analysis results and linkage operation instructions output by the fault reasoning model. The linkage operation instructions are used to instruct the corresponding operation to be performed on the relevant items in the first display area. The four semantic vectors obtained in the previous step are concatenated sequentially into a long vector, which serves as the input feature of the pre-trained fault reasoning model. The fault reasoning model can adopt a Transformer or multilayer perceptron-based architecture and be pre-trained on a large number of vehicle diagnostic dialogues and operation logs. Linkage operation instructions refer to the command codes or parameter sets generated by the fault reasoning model that can be parsed by the system interface layer and drive the first display area to perform specified interactive actions (such as positioning, highlighting, and expanding). The model output includes two parts: first, the diagnostic analysis results, i.e., the root cause, confidence level, and repair suggestions described in natural language or structured text; second, the linkage operation instructions, which are a set of specific automated commands for the first display area, such as "highlight fault code P0135", "mark the selected time period on the data stream curve", and "pop up the heater circuit diagram". For example: After concatenating the four vectors from the previous step and inputting them into the model, the model outputs the diagnostic analysis result text: "An open circuit in the oxygen sensor heater circuit causes the sensor output to be clamped at 0.45V. It is recommended to check the heater resistor and fuse." At the same time, it outputs the linkage operation command.

[0040] In one embodiment, step S5, which involves performing fault analysis based on the information to be diagnosed and the diagnostic data to generate diagnostic analysis results, includes: S511: When there are multiple fault codes in the diagnostic data, calculate the semantic correlation between each fault code and the information to be diagnosed; S512: Generate a priority sorting list for troubleshooting the multiple fault codes based on the semantic correlation, the preset severity level of each fault code, and the system impact range associated with each fault code. S513: The priority ranking list for investigation is included as part of the diagnostic analysis results.

[0041] As described in step S511 above, when multiple fault codes exist in the diagnostic data, the semantic relevance between each fault code and the information to be diagnosed is calculated. This aims to quantify the semantic relevance between each fault code and the diagnostic question posed by the user in natural language, addressing the complex scenario of multiple fault codes appearing simultaneously in the diagnostic data. The semantic relevance can be calculated using various methods: based on the textual similarity between the standard description text of the fault code and the user's question; or by utilizing a domain knowledge graph to calculate the shortest path distance or personalized PageRank. A higher relevance indicates that the fault code is more likely to be a core issue of concern to the user. For example, the diagnostic data contains three fault codes: P0301 (cylinder 1 misfire), P0171 (system too lean), and P0420 (catalytic converter efficiency below threshold). The user enters a natural language question on the interactive interface: "The vehicle idles violently and accelerates weakly. Is this caused by misfire?". The semantic relevance of each fault code is calculated: P0301 is highly matched with "vibration" and "misfire", with a relevance score of 0.92; P0171 is somewhat related to "weak acceleration", but not as directly as misfire, with a score of 0.47; P0420 is weakly related to the above phenomena, with a score of 0.21.

[0042] As described in step S512 above, a priority ranking list for the multiple fault codes is generated based on the semantic relevance, the preset severity level of each fault code, and the system impact range associated with each fault code. The fault codes are ranked by integrating multiple factors, rather than relying solely on semantic matching. Semantic relevance reflects the degree of matching between the user's subjective description and the fault code; the preset severity level can be defined by OBD (On-Board Diagnostics) standards or based on the safety impact classification of the fault code; and the system impact range refers to the subsystems affected by the fault code and its degree of diffusion. A comprehensive score is calculated using a weighted scoring model (e.g., relevance × 0.5 + severity level weight × 0.3 + impact range weight × 0.2), and the priority list is obtained by arranging the scores in descending order. For example, the attributes of the three fault codes are as follows: P0301 has a correlation of 0.92, a severity level of "high" (may cause catalytic converter damage), and an impact range of "partial cylinder 1"; P0171 has a correlation of 0.47, a severity level of "medium", and an impact range of "the entire fuel system"; P0420 has a correlation of 0.21, a severity level of "medium", and an impact range of "aftertreatment system". After weighted calculation, P0301 has the highest overall score (0.92×0.5+1×0.3+0.6×0.2=0.88), followed by P0171 (0.47×0.5+0.6×0.3+0.8×0.2=0.575), and P0420 has the lowest score (0.21×0.5+0.6×0.3+0.5×0.2=0.385). Therefore, the troubleshooting priority is: [P0301, P0171, P0420].

[0043] As described in step S513 above, the priority list for troubleshooting is included as part of the diagnostic analysis results. The diagnostic analysis results not only include conclusive information such as the root cause of the fault and repair recommendations, but also a logical order guiding the repair technician to troubleshoot multiple fault codes sequentially. In the actual interface presentation, this list can be combined with the actions in step S6, for example, by automatically rearranging the fault code list in the first display area, highlighting the highest priority fault code at the top, or by generating a floating panel with a "suggested troubleshooting order." For example, based on the sorted list [P0301, P0171, P0420] obtained from S512, the following content is generated in the diagnostic analysis results: "Based on your description 'idling vibration, weak acceleration' and the fault codes reported by the vehicle, it is recommended to check in the following order: 1. P0301 Cylinder 1 misfire (please check spark plugs, ignition coils and fuel injectors); 2. P0171 System too lean (check intake manifold leaks and oxygen sensor); 3. P0420 Low catalytic converter efficiency (verify whether the catalytic converter is damaged after resolving the misfire problem)." This list is also encoded as structured data, and the sorting and display labels are automatically and dynamically adjusted in the fault code table in the first display area.

[0044] In one embodiment, step S6, which involves performing corresponding operations on relevant items in the diagnostic interface displayed in the first display area based on the diagnostic analysis results, includes: S611: Display the sorting list of investigation priorities in the second display area; S612: In response to the user's selection of a fault code in the sorted list, scroll to the location of the fault code in the first display area and expand the sub-information window corresponding to the fault code; wherein, the sub-information window contains a description of the fault code, possible causes of the fault, and links to preset repair steps.

[0045] As described in step S611 above, the troubleshooting priority sorting list is displayed in the second display area. The fault code troubleshooting priority sorting list generated in step S513 is presented in a visual manner in the second display area. The second display area was originally used to receive user natural language input, but its function is further expanded here to serve as a diagnostic suggestion output panel. The display format can be a list of items with serial numbers, fault code numbers, and brief descriptions, and can be combined with colors or icons to distinguish between high and low priorities. For example: following the example of S512 / S513, the troubleshooting priority sorting is P0301 (cylinder 1 misfire), P0171 (system too lean), P0420 (catalytic converter inefficiency). A card component with a border is generated in the second display area (interactive interface) on the right, titled "Suggested Troubleshooting Order", with three clickable buttons or list items listed below: "1. [High Priority] P0301 - Cylinder 1 Misfire", "2. [Medium Priority] P0171 - System Too Lean", "3. [Low Priority] P0420 - Catalytic Converter Inefficiency". Each item is accompanied by a brief icon (such as a spark plug icon representing a fire), and the highest priority item is highlighted in light yellow by default.

[0046] As described in step S612 above, in response to the user's selection of a fault code from the sorted list, the system scrolls to the location of the fault code in the first display area and expands the corresponding sub-information window. The sub-information window contains a description of the fault code, possible causes of the fault, and links to preset repair steps. This step enables cross-regional linkage: after the user clicks on a fault code list item in the second display area, the system automatically operates the first display area, scrolling to the specific location of the fault code in the original fault code table or list, and automatically expanding its associated sub-information window. The sub-information window may have been collapsed or not currently visible; the scrolling operation ensures that the fault code is brought to the center of the field of view, while the expansion operation provides detailed auxiliary information, including the standard description of the fault code, possible causes of the fault, and links to preset repair steps. For example, a repair technician clicks on "P0301 - Cylinder 1 misfire" in the second display area. At this point, the first display area, which originally showed a table containing more than ten fault codes, uses a table row positioning algorithm to locate the row with fault code P0301 and automatically scrolls (with a smooth animation) to vertically center the row in the first display area. At the same time, the sub-information window that was originally hidden to the right or below the row (usually expanded by a small arrow or a "Details" button) automatically pops up, displaying: "Description: Cylinder 1 detected a misfire event; Possible causes: Ignition coil failure, spark plug gap too large, fuel injector blockage, insufficient cylinder compression pressure; Repair steps link: Click to view the cylinder 1 misfire diagnosis process (link points to local or cloud knowledge base)". To enhance the visual feedback, the row containing the fault code will also briefly flash a green border.

[0047] In one embodiment, after step S6 of performing corresponding operations on relevant items in the diagnostic interface displayed in the first display area based on the diagnostic analysis results, the method further includes: S701: Save the natural language diagnostic questions and their corresponding intent recognition results received each time through the second display area to form a dialogue history; S702: Determine whether a new natural language diagnostic question has been received through the second display area; S703: If a new natural language diagnostic question is received through the second display area, the dialogue history and the current question are input together for intent recognition and entity extraction to obtain new diagnostic information; S704: Perform fault analysis based on the new information to be diagnosed and the diagnostic data to generate new diagnostic analysis results; S705: Based on the new diagnostic analysis results, perform corresponding operations on the relevant items in the diagnostic interface displayed in the first display area.

[0048] As described in step S701 above, each natural language diagnostic question received through the second display area and its corresponding intent recognition result are saved to form a dialogue history. Each time a user inputs a natural language question (such as "Why is the engine shaking?") in the second display area, after intent recognition (e.g., intent classification as "fault phenomenon analysis") and entity extraction are completed, this information is not discarded, but is persistently stored in memory or a local database to form a dialogue record. Each record contains at least the original question text, timestamp, identified intent tag, and extracted entity key-value pairs. Multiple consecutive question-and-answer pairs constitute the dialogue history, which can be referenced in subsequent multi-round interactions. For example, if a user's first input is "Why does the engine idle violently?", the system recognizes the intent as "explanation of the phenomenon" and the entity as [phenomenon = idle vibration]. This entry is saved as a history H1={query:"Why does the engine idle violently?",intent:"explanation of the phenomenon",entities:{symptom:"idling vibration"},timestamp:T1}. Later, if the user asks "Does that have anything to do with the throttle body?", without saving the history, it's impossible to understand what "that" refers to. However, with the dialogue history, it's possible to connect it to the question object from the previous round.

[0049] As described in step S702 above, the second display area is used to determine whether a new natural language diagnostic question has been received. This is a loop monitoring process used to detect whether the user has initiated a new round of questions on the interactive interface. The determination methods include: monitoring whether the content of the input box is not empty and whether the user has clicked the "send" button or pressed the Enter key, or detecting the voice input completion event. If there is no new question, it can wait or enter an idle state; once a new question is detected, the subsequent processing flow is triggered. For example: after displaying the first diagnostic analysis result (e.g., "Check the ignition system"), the user observes that some data stream parameters in the first display area have changed, and then enters a new question in the text box of the second display area: "What changes have occurred in the data stream after changing the spark plugs?", the event monitoring module captures the "newline + send" operation in the input box, determines that a new natural language diagnostic question has been received, and immediately extracts the text and sends it to the next processing flow.

[0050] As described in step S703 above, when a new natural language diagnostic question is received through the second display area, the dialogue history and the current question are input together for intent recognition and entity extraction to obtain new diagnostic information. Processing the current question alone may produce ambiguity or missing information. However, concatenating the dialogue history with the current question or using it as input to the interaction attention model can fill in omitted subjects, time references, or operation objects. The intent recognition and entity extraction module will comprehensively consider entities and intents in the historical record, thereby generating more accurate diagnostic information. For example, the dialogue history records the previous question "Why does the engine idle violently?" and the entity {phenomenon = idle violently}. The current new question is "Will it cause increased fuel consumption?" Without the history, the model cannot understand the meaning of "it". After inputting the dialogue history and the current question together, the model recognizes that "it" refers to the previous entity "idling violently", thus correctly extracting the diagnostic information: the intent is "causal impact analysis", and the entity is [precursor phenomenon = idle violently, consequence phenomenon = increased fuel consumption]. If a user's question is "Why did the data stream change after I changed the spark plugs?", even though the "spark plugs were changed" part of the historical data is not in the current sentence, the model can still establish a connection between the operation and the current observation through the history.

[0051] As described in step S704 above, fault analysis is performed based on the new information to be diagnosed and the diagnostic data to generate new diagnostic analysis results. Using the new information to be diagnosed obtained in step S703, combined with the vehicle's original diagnostic data, the fault analysis is re-executed. Unlike the first round of analysis, the new analysis can be deepened or adjusted based on previous diagnostic conclusions. For example, the user may inquire about parameter changes in a specific component, or a previously checked fault cause may be ruled out. The analysis engine can be designed to support incremental reasoning, that is, updating the results of the previous round of analysis based on new information, rather than calculating from scratch, and outputting new diagnostic analysis results, which may include updated root causes, confidence adjustments, or further verification steps. For example, based on the historical operation information of "spark plugs replaced" and the current new diagnostic information "what changes have occurred in the data stream", the latest real-time data stream in the first display area is obtained. It is found that the misfire count of cylinder 1 has decreased from 50 times to 2 times, but the oxygen sensor voltage is still fluctuating abnormally. Therefore, a new diagnostic analysis result is generated: "The misfire problem has been basically resolved after replacing the spark plugs, but the oxygen sensor voltage is still abnormal (currently fluctuating irregularly between 0.1-0.9V). There may be a vacuum leak or fuel injector blockage. It is recommended to check the intake manifold and fuel pressure." As described in step S705 above, based on the new diagnostic analysis results, corresponding operations are performed on the relevant items in the diagnostic interface displayed in the first display area. The system automatically performs corresponding visual or control operations in the first display area based on the new analysis results, such as canceling the previous highlighting of fault codes, highlighting new related data items instead, popping up a new maintenance guidance window, automatically adding annotations, or adjusting the vertical axis range of the data stream curve. For example, based on the new diagnostic analysis result "vacuum leak or fuel injector blockage" generated in S704, the system performs the following operations in the first display area: ① Cancels the previous red highlighting of fault code P0301 (because the misfire has been alleviated); ② Highlights the "intake manifold absolute pressure" parameter in the data stream in blue and automatically marks the abnormal fluctuation area on the curve; ③ Pops up a floating prompt box: "It is recommended to perform a smoke test to check for vacuum leaks"; ④ If P0171 (system too lean) is present in the fault code list, its sub-information window is automatically expanded, and the possible cause "intake leak" is highlighted. The entire operation requires no user intervention and is entirely driven by the new analysis results.

[0052] In one embodiment, step S5, which involves performing fault analysis based on the information to be diagnosed and the diagnostic data to generate diagnostic analysis results, includes: S521: Continuously collect real-time data streams of the vehicle and monitor whether the values ​​of each data item in the real-time data stream exceed the corresponding preset threshold. S522: If the value of a certain data item exceeds its preset threshold, the data item is marked as an abnormal data item, and the abnormal data item and the extent to which it exceeds the threshold are included as part of the diagnostic data. S523: Associate and match the abnormal data item with the fault code in the diagnostic data; S524: If the correlation between a fault code and at least one abnormal data item exceeds a preset threshold, then the causal relationship description between the fault code and the abnormal data item is output in the diagnostic analysis results.

[0053] As described in step S521 above, the vehicle's real-time data stream is continuously collected, and the values ​​of each data item in the real-time data stream are monitored to see if they exceed the corresponding preset thresholds. Instead of passively waiting for user queries or fault code triggers, the system actively monitors the dynamic parameters of the vehicle during operation. Real-time data streams are continuously collected at a fixed frequency (e.g., 10 times per second) through diagnostic interfaces [such as OBD-II (On-Board Diagnostics II) or UDS (Unified Diagnostic Services)]. These data streams include common parameters such as engine speed, vehicle speed, coolant temperature, oxygen sensor voltage, intake pressure, and throttle opening. Each data item corresponds to a pre-configured threshold. The monitoring module continuously compares the current value with the threshold, and marks any value exceeding the range as a potential anomaly. For example, the vehicle diagnostic system collects real-time data streams from a diesel truck at 100ms intervals. The upper limit of the exhaust temperature threshold is set to 650℃. Under heavy load climbing conditions, the exhaust temperature was monitored to reach 710℃, 720℃, and 715℃ for three consecutive seconds, all exceeding the 650℃ threshold. At the same time, the upper limit of the boost pressure data item threshold was monitored to be 2.5 bar, and the actual value reached 2.8 bar. Both data items triggered the judgment of exceeding the threshold.

[0054] As described in step S522 above, if the value of a data item exceeds its preset threshold, the data item is marked as an abnormal data item, and the abnormal data item and the magnitude of its exceeding the threshold are included as part of the diagnostic data. After being marked as an "abnormal data item," not only is the name and current value of the data item recorded, but the magnitude of exceeding the threshold is also calculated, such as an absolute difference or a relative percentage. In addition, the duration of the exceedance and the operating conditions at the time of occurrence can also be included. This information is dynamically added to the diagnostic data set, alongside existing fault codes, system information, etc., for subsequent fault analysis. For example: following S521, "exhaust temperature" is marked as an abnormal data item, recording its current maximum value of 720℃, threshold of 650℃, exceedance of 70℃ (relative magnitude 10.8%), duration of 3 seconds, and operating conditions of "vehicle speed 45km / h, gradient approximately 6%". At the same time, "boost pressure" is marked as an abnormal data item, with a current value of 2.8 bar, threshold of 2.5 bar, and exceedance of 0.3 bar (12%). These two abnormal records are added to the diagnostic data structure.

[0055] As described in step S523 above, the abnormal data items are associated and matched with the fault codes in the diagnostic data. Matching is performed based on predefined domain knowledge rules or using an association model trained on historical maintenance data. The result of the matching is to calculate the association degree (score between 0 and 1) between each fault code and each abnormal data item. For example, in the diagnostic data, there are existing fault codes P0238 (turbocharger boost sensor A circuit high input) and P0540 (exhaust temperature sensor circuit fault). The abnormal data item "exhaust temperature 720℃" is matched with these fault codes. According to the rule base, excessively high exhaust temperature is usually not directly caused by an exhaust temperature sensor circuit fault, but rather by excessive boost pressure leading to an increase in exhaust temperature. Therefore, the correlation between P0238 and exhaust temperature is calculated to be 0.85, while the correlation between P0540 and this abnormal data item is only 0.15 (sensor faults may cause reading deviations, but here the temperature is actually higher). Meanwhile, the abnormal data item "boost pressure 2.8 bar" has a high correlation of 0.95 with P0238 (directly related) and a correlation of 0.10 with P0540.

[0056] As described in step S524 above, if the correlation between a fault code and at least one abnormal data item exceeds a preset threshold, a causal relationship description between the fault code and the abnormal data item is output in the diagnostic analysis results. The preset threshold (e.g., 0.7) is used to filter out weak correlation combinations, outputting only high-confidence causal relationship descriptions. The description must explicitly express in natural language that "fault code X caused abnormal data item Y" or "abnormal data item Y may be a specific manifestation of fault code X," and should provide directional and mechanistic explanations as much as possible. For example, in S523, the correlation between fault code P0238 and exhaust temperature (0.85) and the correlation with boost pressure (0.95) both exceed the preset threshold of 0.7. The diagnostic analysis results will output the following causal description: "Fault code P0238 (Turbocharger boost sensor A circuit high input) causes the engine control system to misjudge the boost pressure, resulting in an excessively high actual boost pressure (2.8 bar), which in turn causes the exhaust temperature to exceed the threshold (720℃). It is recommended to first check the boost sensor and its wiring, and verify whether the wastegate valve actuator is stuck." If another fault code P0540 has a correlation with all abnormal items below the threshold, its causal relationship with the abnormal items will not be output to avoid misleading repair personnel.

[0057] Reference Figure 3 The present invention provides a vehicle diagnostic device based on information interaction, the device comprising: The acquisition module 902 is used to acquire vehicle diagnostic data, which includes at least one of system information, fault codes, real-time data streams, and control unit status information. The first judgment module 904 is used to determine whether there is abnormal information in the diagnostic data. If there is abnormal information, the screen is split on a preset screen to obtain a first display area and a second display area. The first display area displays the diagnostic interface, and the second display area provides an interactive interface. The first receiving module 906 is used to receive natural language diagnostic questions input by the user through the second display area; Extraction module 908 is used to perform intent recognition and entity extraction on the natural language diagnostic problem to obtain the information to be diagnosed; The first generation module 910 is used to perform fault analysis based on the information to be diagnosed and the diagnostic data, and generate diagnostic analysis results. The first execution module 912 is used to perform corresponding operations on the relevant items in the diagnostic interface displayed in the first display area according to the diagnostic analysis results.

[0058] In one embodiment, the first generation module 910 includes: The operation information acquisition submodule is used to acquire the user's operation information on the first display area; The context display information acquisition submodule is used to acquire the context display information of the first display area based on the operation information; The fault analysis submodule is used to perform fault analysis based on the operation information, the context display information, the information to be diagnosed, and the diagnostic data, and generate diagnostic analysis results.

[0059] In one embodiment, the fault analysis submodule includes: The conversion unit is used to convert the operation information into a first semantic vector, the context display information into a second semantic vector, the information to be diagnosed into a third semantic vector, and the diagnostic data into a fourth semantic vector. The splicing unit is used to splice the first semantic vector, the second semantic vector, the third semantic vector, and the fourth semantic vector and then input them into the pre-trained fault reasoning model to obtain the fault reasoning model outputs diagnostic analysis results and linkage operation instructions; wherein, the linkage operation instructions are used to instruct the relevant items in the first display area to perform corresponding operations.

[0060] In one embodiment, the first generation module 910 includes: The semantic correlation calculation submodule is used to calculate the semantic correlation between each fault code and the information to be diagnosed when there are multiple fault codes in the diagnostic data. The priority sorting list generation submodule is used to generate a priority sorting list for the multiple fault codes based on the semantic relevance, the preset severity level of each fault code, and the system impact range associated with each fault code. The tagging submodule is used to include the priority sorting list as part of the diagnostic analysis results.

[0061] In one embodiment, the first execution module 912 includes: The display submodule is used to display the sorting list of investigation priorities in the second display area; The response submodule is used to respond to the user's selection of a fault code in the sorted list by scrolling to the location of the fault code in the first display area and expanding the sub-information window corresponding to the fault code; wherein, the sub-information window contains a description of the fault code, possible causes of the fault, and links to preset repair steps.

[0062] In one embodiment, the vehicle diagnostic device based on information interaction further includes: The storage module is used to save each natural language diagnostic question received through the second display area and its corresponding intent recognition result, forming a dialogue history. The second judgment module is used to determine whether a new natural language diagnostic question has been received through the second display area; The second receiving module is used to input the dialogue history and the current question together for intent recognition and entity extraction when a new natural language diagnostic question is received through the second display area, so as to obtain new diagnostic information. The second generation module is used to perform fault analysis based on the new information to be diagnosed and the diagnostic data, and generate new diagnostic analysis results. The second execution module is used to perform corresponding operations on the relevant items in the diagnostic interface displayed in the first display area based on the new diagnostic analysis results.

[0063] In one embodiment, the first generation module 910 includes: The acquisition submodule is used to continuously acquire real-time data streams of vehicles and monitor whether the values ​​of each data item in the real-time data stream exceed the corresponding preset threshold. An abnormal data item marking submodule is used to mark a data item as an abnormal data item if the value of a certain data item exceeds its preset threshold, and to include the abnormal data item and the extent to which it exceeds the threshold as part of the diagnostic data. The association matching submodule is used to associate and match the abnormal data items with the fault codes in the diagnostic data; The output submodule is used to output a description of the causal relationship between a fault code and at least one abnormal data item in the diagnostic analysis results if the correlation between a fault code and at least one abnormal data item exceeds a preset threshold.

[0064] Figure 4 An internal structural diagram of an electronic device in one embodiment is shown. This electronic device can specifically be a terminal or a server, and more specifically, a computer device. Figure 4 As shown, the electronic device includes a processor, a memory, and a network interface connected via a system bus. The memory includes a non-volatile storage medium and internal memory. The non-volatile storage medium stores an operating system and may also store a computer program. When executed by the processor, this computer program enables the processor to implement a vehicle diagnostic method based on information interaction. The internal memory may also store a computer program, which, when executed by the processor, enables the processor to implement a vehicle diagnostic method based on information interaction. Those skilled in the art will understand that... Figure 4 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the electronic device to which the present application is applied. The specific electronic device may include more or fewer components than shown in the figure, or combine certain components, or have different component arrangements.

[0065] In one embodiment, an electronic device is provided, including a memory and a processor, the memory storing a computer program that, when executed by the processor, causes the processor to perform the following steps: Acquire vehicle diagnostic data, which includes at least one of system information, fault codes, real-time data streams, and control unit status information; Determine whether there is abnormal information in the diagnostic data. If there is abnormal information, perform screen splitting on a preset screen to obtain a first display area and a second display area. The first display area displays the diagnostic interface, and the second display area provides an interactive interface. The second display area receives natural language diagnostic questions input by the user. The natural language diagnostic problem is subjected to intent recognition and entity extraction to obtain the information to be diagnosed; Based on the information to be diagnosed and the diagnostic data, a fault analysis is performed to generate diagnostic analysis results; Based on the diagnostic analysis results, perform corresponding operations on the relevant items in the diagnostic interface displayed in the first display area.

[0066] By acquiring vehicle diagnostic data and identifying anomalies, the system automatically performs split-screen processing when an anomaly is detected. Users can directly input diagnostic questions in natural language in the second display area, and the system performs intent recognition and entity extraction. Users do not need to learn technical terms or memorize menu paths, which significantly reduces the operational threshold. Then, based on the information to be diagnosed and the diagnostic data, the system performs fault analysis and generates diagnostic analysis results. According to the analysis results, the system automatically performs operations such as locating, highlighting, or expanding relevant items in the first display area, directly mapping the analysis conclusions to specific relevant items. This avoids the tedious process of users manually searching and switching interfaces, and improves the efficiency of fault diagnosis.

[0067] In one embodiment, a computer-readable storage medium is provided storing a computer program that, when executed by a processor, causes the processor to perform the following steps: Acquire vehicle diagnostic data, which includes at least one of system information, fault codes, real-time data streams, and control unit status information; Determine whether there is abnormal information in the diagnostic data. If there is abnormal information, perform screen splitting on a preset screen to obtain a first display area and a second display area. The first display area displays the diagnostic interface, and the second display area provides an interactive interface. The second display area receives natural language diagnostic questions input by the user. The natural language diagnostic problem is subjected to intent recognition and entity extraction to obtain the information to be diagnosed; Based on the information to be diagnosed and the diagnostic data, a fault analysis is performed to generate diagnostic analysis results; Based on the diagnostic analysis results, perform corresponding operations on the relevant items in the diagnostic interface displayed in the first display area.

[0068] By acquiring vehicle diagnostic data and identifying anomalies, the system automatically performs split-screen processing when an anomaly is detected. Users can directly input diagnostic questions in natural language in the second display area, and the system performs intent recognition and entity extraction. Users do not need to learn technical terms or memorize menu paths, which significantly reduces the operational threshold. Then, based on the information to be diagnosed and the diagnostic data, the system performs fault analysis and generates diagnostic analysis results. According to the analysis results, the system automatically performs operations such as locating, highlighting, or expanding relevant items in the first display area, directly mapping the analysis conclusions to specific relevant items. This avoids the tedious process of users manually searching and switching interfaces, and improves the efficiency of fault diagnosis.

[0069] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments described above. Any references to memory, storage, databases, or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), RAMbus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and RAMbus dynamic RAM (RDRAM), etc.

[0070] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

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

Claims

1. A vehicle diagnostic method based on information interaction, characterized in that, The method includes: Acquire vehicle diagnostic data, which includes at least one of system information, fault codes, real-time data streams, and control unit status information; Determine whether there is abnormal information in the diagnostic data. If there is abnormal information, perform screen splitting on a preset screen to obtain a first display area and a second display area. The first display area displays the diagnostic interface, and the second display area provides an interactive interface. The second display area receives natural language diagnostic questions input by the user. The natural language diagnostic problem is subjected to intent recognition and entity extraction to obtain the information to be diagnosed; Based on the information to be diagnosed and the diagnostic data, a fault analysis is performed to generate diagnostic analysis results; Based on the diagnostic analysis results, perform corresponding operations on the relevant items in the diagnostic interface displayed in the first display area.

2. The vehicle diagnostic method based on information interaction according to claim 1, characterized in that, The step of performing fault analysis based on the information to be diagnosed and the diagnostic information to generate diagnostic analysis results includes: Obtain user operation information for the first display area; Based on the operation information, obtain the context display information of the first display area; Based on the operation information, the context display information, the information to be diagnosed, and the diagnostic data, fault analysis is performed to generate diagnostic analysis results.

3. The vehicle diagnostic method based on information interaction according to claim 2, characterized in that, The step of performing fault analysis based on the operation information, the context display information, the information to be diagnosed, and the diagnostic data to generate diagnostic analysis results includes: The operation information is converted into a first semantic vector, the context display information is converted into a second semantic vector, the information to be diagnosed is converted into a third semantic vector, and the diagnostic data is converted into a fourth semantic vector. The first semantic vector, the second semantic vector, the third semantic vector, and the fourth semantic vector are concatenated and then input into a pre-trained fault reasoning model to obtain the fault reasoning model outputs diagnostic analysis results and linkage operation instructions; wherein, the linkage operation instructions are used to instruct the corresponding operation to be performed on the relevant items in the first display area.

4. The vehicle diagnostic method based on information interaction according to claim 1, characterized in that, The step of performing fault analysis based on the information to be diagnosed and the diagnostic data to generate diagnostic analysis results includes: When multiple fault codes exist in the diagnostic data, the semantic correlation between each fault code and the information to be diagnosed is calculated separately. Based on the semantic relevance, the preset severity level of each fault code, and the system impact range associated with each fault code, a priority ranking list for troubleshooting the multiple fault codes is generated. The priority list for investigation is included as part of the diagnostic analysis results.

5. The vehicle diagnostic method based on information interaction according to claim 4, characterized in that, The step of performing corresponding operations on relevant items in the diagnostic interface displayed in the first display area based on the diagnostic analysis results includes: The priority sorting list for the investigation is displayed in the second display area; In response to the user's selection of a fault code in the sorted list, the system scrolls to the location of the fault code in the first display area and expands the corresponding sub-information window; wherein the sub-information window contains a description of the fault code, possible causes of the fault, and links to preset repair steps.

6. The vehicle diagnostic method based on information interaction according to claim 1, characterized in that, After the step of performing corresponding operations on the relevant items in the diagnostic interface displayed in the first display area based on the diagnostic analysis results, the method further includes: Save the natural language diagnostic questions and their corresponding intent recognition results received each time through the second display area to form a dialogue history; The second display area is used to determine whether a new natural language diagnostic question has been received. If a new natural language diagnostic question is received through the second display area, the dialogue history and the current question are input together for intent recognition and entity extraction to obtain new diagnostic information; Based on the new information to be diagnosed and the diagnostic data, fault analysis is performed to generate new diagnostic analysis results. Based on the new diagnostic analysis results, perform corresponding operations on the relevant items in the diagnostic interface displayed in the first display area.

7. The vehicle diagnostic method based on information interaction according to claim 1, characterized in that, The step of performing fault analysis based on the information to be diagnosed and the diagnostic data to generate diagnostic analysis results includes: Continuously collect real-time data streams of vehicles and monitor whether the values ​​of each data item in the real-time data stream exceed the corresponding preset thresholds; If the value of a certain data item exceeds its preset threshold, the data item is marked as an abnormal data item, and the abnormal data item and the extent to which it exceeds the threshold are included as part of the diagnostic data. The abnormal data items are associated and matched with the fault codes in the diagnostic data; If the correlation between a fault code and at least one abnormal data item exceeds a preset threshold, a description of the causal relationship between the fault code and the abnormal data item will be output in the diagnostic analysis results.

8. A vehicle diagnostic device based on information interaction, characterized in that, The device includes: The acquisition module is used to acquire vehicle diagnostic data, which includes at least one of system information, fault codes, real-time data streams, and control unit status information. The first judgment module is used to determine whether there is abnormal information in the diagnostic data. If there is abnormal information, the screen is split on a preset screen to obtain a first display area and a second display area. The first display area displays the diagnostic interface, and the second display area provides an interactive interface. The first receiving module is used to receive natural language diagnostic questions input by the user through the second display area; The extraction module is used to perform intent recognition and entity extraction on the natural language diagnostic question to obtain the information to be diagnosed; The first generation module is used to perform fault analysis based on the information to be diagnosed and the diagnostic data, and generate diagnostic analysis results. The first execution module is used to perform corresponding operations on the relevant items in the diagnostic interface displayed in the first display area based on the diagnostic analysis results.

9. A computer-readable storage medium, characterized in that, The system contains a computer program that, when executed by a processor, causes the processor to perform the steps of the vehicle diagnostic method based on information interaction as described in any one of claims 1 to 7.

10. An electronic device, characterized in that, The device includes a memory and a processor, the memory storing a computer program that, when executed by the processor, causes the processor to perform the steps of the information interaction-based vehicle diagnostic method as described in any one of claims 1 to 7.

Images