Diagnosis interface display method and device, electronic equipment and storage medium
By analyzing the repair feasibility of fault codes using language models and dynamically generating diagnostic interfaces, the problem of cumbersome traditional automotive diagnostic interfaces is solved, improving diagnostic efficiency and user experience.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-12-01
- Publication Date
- 2026-04-14
AI Technical Summary
Current automotive diagnostic equipment has a complex diagnostic interface and confusing operation path, making it difficult for non-professional users to effectively diagnose faults, resulting in poor diagnostic results and a bad user experience.
By analyzing the repair feasibility of fault codes using a language model, a diagnostic interface that matches the repair feasibility is dynamically generated, including displaying executable operation controls and guidance information to avoid invalid operations.
The diagnostic interface has been simplified, the operation path has been clarified, and the diagnostic efficiency and user experience have been improved, especially the ease of operation for non-professional users.
Smart Images

Figure CN121858595A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of vehicle technology, specifically to a diagnostic interface display method, device, electronic device, and storage medium. Background Technology
[0002] Currently, with the rapid popularization and development of automobiles, cars typically require regular maintenance and fault diagnosis. During fault diagnosis, repair personnel use diagnostic equipment to detect faults in the vehicle. Most current diagnostic equipment has a fixed interface, listing all functions at once. This interface is complex and the operation path is confusing. If users attempt to perform diagnostics without professional knowledge, it may lead to operation failure, resulting in poor diagnostic results and a bad user experience. Summary of the Invention
[0003] This application provides a diagnostic interface display method, device, electronic device, and storage medium to solve the problems of poor diagnostic results and user experience.
[0004] To achieve the above objectives, according to a first aspect of this application, a diagnostic interface display method is provided, applied to a diagnostic device, the method comprising: The diagnostic information of the target vehicle diagnosed by the diagnostic device is displayed, and the diagnostic information includes the diagnostic results of at least one component in the target vehicle. In response to a triggering operation on a target component in the components, if the diagnostic result of the target component includes a target fault code, the target fault code is processed according to a language model to obtain the repair feasibility corresponding to the target fault code. Based on the repair feasibility, determine the diagnostic function interaction element corresponding to the target vehicle under the target fault code, and the diagnostic function interaction element is associated with the fault indicated by the target fault code; Based on the diagnostic function interactive elements, the target diagnostic interface corresponding to the repair feasibility is displayed.
[0005] Optionally, the method further includes: If the diagnostic results for the target component do not include the target fault code, a preset general interface for the component is displayed.
[0006] Optionally, the step of processing the target fault code according to the language model to obtain the repair feasibility corresponding to the target fault code includes: Obtain vehicle information of the target vehicle and current scene information of the target vehicle, wherein the current scene information includes at least one of the geographical information, environmental information and equipment information of the target vehicle. Based on the vehicle information and the target fault code, the target repair conditions corresponding to the target fault code are determined using a language model. Determine whether the current scenario information meets the target maintenance conditions corresponding to the target fault code, so as to determine the maintenance feasibility corresponding to the target fault code; The target maintenance conditions include at least one of the following conditions: Does the geographic information meet the target road conditions? Does the environmental information meet the target environmental conditions? Does the user's identity information match the target user's identity information? Does the device information match the target device information?
[0007] Optionally, displaying the target diagnostic interface corresponding to the repair feasibility based on the diagnostic function interaction elements includes: If the current scenario information meets the target repair conditions, the repair feasibility is determined to be repairable, and the target diagnostic interface is displayed based on the diagnostic function interaction elements; or; If the current scenario information does not meet the target repair conditions, the repair feasibility is determined to be unrepairable, and the general repair interface for the target fault code is displayed. The general repair interface for the fault code includes the repair guidance materials corresponding to the target fault code.
[0008] Optionally, the diagnostic function interaction elements include at least one of the following: a fault code reading control, a fault code clearing control, a data stream control, a test function control, a special function control, a calibration function control, and a flashing function control.
[0009] Optionally, determining the diagnostic function interaction element corresponding to the target vehicle under the target fault code based on the repair feasibility includes: In the case of repairability, based on the mapping relationship between preset fault codes and preset diagnostic function interaction elements, and the target fault code, a diagnostic function interaction element matching the target fault code is determined.
[0010] Optionally, when the target fault code is a calibration type fault code, the diagnostic function interaction element matching the target fault code includes at least a calibration function control; or When the target fault code is a software type fault code, the diagnostic function interaction element matching the target fault code includes at least a write function control.
[0011] According to a second aspect of this application, embodiments of this application also provide a diagnostic interface display device, the device comprising: A diagnostic module is used to display diagnostic information of a target vehicle diagnosed by a diagnostic device, the diagnostic information including the diagnostic results of at least one component in the target vehicle; The judgment module is used to respond to a trigger operation on a target component in the components, and when the diagnostic result of the target component includes a target fault code, to process the target fault code according to a language model to obtain the repair feasibility corresponding to the target fault code. The determination module is used to determine, based on the repair feasibility, the diagnostic function interaction element corresponding to the target vehicle under the target fault code, wherein the diagnostic function interaction element is associated with the fault indicated by the target fault code; The display module is used to display the target diagnostic interface corresponding to the repair feasibility based on the diagnostic function interactive elements.
[0012] According to a third aspect of this application, embodiments of this application also provide an electronic device, comprising: A memory on which computer programs are stored; A processor is configured to execute the computer program in the memory to implement the steps of any of the methods provided in the embodiments of this application.
[0013] According to a fourth aspect of this application, embodiments of this application also provide a computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the steps of any of the methods provided in embodiments of this application.
[0014] Some embodiments of this application include at least the following beneficial effects: by analyzing fault codes at the initial stage of diagnosis, the repair feasibility of each fault code is automatically determined, and a diagnostic interface matching the repair feasibility is dynamically generated. The diagnostic interface is more concise, the operation path is clear, and thus the human-computer interaction experience is optimized, making the diagnostic process smoother and more efficient.
[0015] Other features and advantages of this application will be described in detail in the following detailed description section. Attached Figure Description
[0016] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0017] Figure 1 These are application scenario diagrams of the diagnostic interface display method provided in some embodiments of this application; Figure 2This is a schematic flowchart of a diagnostic interface display method provided in some embodiments of this application; Figure 3 This is an exemplary schematic diagram of a fault code list interface provided in some embodiments of this application; Figure 4 This is an exemplary schematic diagram of a general interface for components provided in some embodiments of this application; Figure 5 This is an exemplary schematic diagram of a target diagnostic interface provided in some embodiments of this application; Figure 6 This is an exemplary schematic diagram of a diagnostic interface display device provided in some embodiments of this application; Figure 7 These are exemplary schematic diagrams of electronic devices provided in some embodiments of this application. Detailed Implementation
[0018] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. All other embodiments obtained by those skilled in the art based on the embodiments of this application without creative effort are within the protection scope of this application.
[0019] With the increasing electrification and intelligence of automobiles, modern vehicles integrate a large number of complex electronic control systems, such as Advanced Driver Assistance Systems (ADAS), in-vehicle infotainment systems, and multi-domain electronic control units (ECUs). The diagnosis and repair of vehicle faults are becoming increasingly complex. Traditional diagnostic equipment can only provide static fault code readings and function menus, resulting in cluttered interfaces, low diagnostic efficiency, and a poor user experience.
[0020] In view of this, some embodiments of this application provide a diagnostic interface display method, which analyzes the repair feasibility of vehicle faults through a language model, realizes dynamic guidance for fault diagnosis, and can improve diagnostic efficiency and subsequent repair results.
[0021] Figure 1 This is an application scenario diagram of the diagnostic interface display method provided in some embodiments of this application.
[0022] The implementing entity of the technical solution in this application embodiment can be an electronic device, which can be implemented in hardware and / or software and can be configured in any electronic device with computing, communication, and environmental perception capabilities. This electronic device can be a dedicated diagnostic instrument, a tablet computer, a smartphone, or an in-vehicle infotainment system or telematics control unit (TCU) integrated into a vehicle.
[0023] like Figure 1 As shown, the method provided in the embodiments of this application can be applied to, for example... Figure 1 The application environment shown can include a terminal (e.g., a diagnostic terminal), a server, and a target vehicle. Taking a diagnostic terminal as an example, the diagnostic terminal and the server establish a data connection through a communication network, which includes, but is not limited to, cellular mobile networks (e.g., 4G / 5G), Wi-Fi LANs, or wired Ethernet. Simultaneously, the diagnostic terminal and the target vehicle can establish a local connection through an on-board diagnostic interface (OBD-II) or wireless communication methods (e.g., Bluetooth, Wi-Fi Direct) to enable real-time reading of vehicle information and sending of diagnostic commands.
[0024] In some embodiments, the diagnostic terminal can be a fixed device, such as a terminal installed at a workstation in an automotive sales and service organization (e.g., a 4S shop or repair station); or it can be a portable device, such as a handheld diagnostic tool, tablet computer, or smartphone, carried by the automotive diagnostic personnel or vehicle owner. The diagnostic terminal is equipped with intelligent diagnostic software for executing the diagnostic interface display method described in the embodiments of this application.
[0025] In some embodiments, after the diagnostic software starts, it first establishes a communication link with the target vehicle and reads information such as the vehicle's Diagnostic Trouble Code (DTC) and vehicle information. The vehicle information includes at least: Vehicle Identification Number (VIN), the model and current firmware version of each ECU, and sensor status.
[0026] The server can be a back-end service system, a cloud platform, or a third-party intelligent diagnostic platform. The server stores fault knowledge bases, repair solution bases, available software versions, and parts information for each vehicle model and each ECU.
[0027] After obtaining the vehicle's fault codes, the language model deployed in the diagnostic terminal or server can analyze the current vehicle information, as well as multi-dimensional information such as geographical location, environmental information, and device connection status, to determine the repair feasibility of each fault code (such as whether the ADAS calibration site conditions are met and whether ECU programming capabilities are available). Subsequently, based on the judgment results, a diagnostic sub-interface matching the current scenario is dynamically generated to provide users with clear and feasible operation guidance.
[0028] The language model can be a large language model (LLM), which can be composed of an artificial neural network with many parameters (usually billions or more weights) and trained using self-supervised learning or semi-supervised learning.
[0029] It is worth noting that the application scenarios described in this application are provided for illustrative purposes only and are not intended to limit the scope of this specification. Those skilled in the art can make various changes and modifications based on the description in this specification. For example, the application scenarios may also include databases, information sources, etc. Furthermore, the application scenarios may be implemented on other devices to achieve similar or different functions. However, these changes and modifications will not depart from the scope of this specification.
[0030] Figure 2 This is a schematic flowchart of a diagnostic interface display method provided in some embodiments of this application. In some embodiments, process 200 can be executed based on an electronic device. Figure 2 As shown, process 200 includes the following steps.
[0031] Step 210: Display the diagnostic information of the target vehicle diagnosed by the diagnostic device. The diagnostic information includes the diagnostic results of at least one component in the target vehicle.
[0032] The target vehicle is the vehicle being tested and analyzed by the diagnostic equipment. For example, the target vehicle may include, but is not limited to, passenger cars, commercial vehicles, new energy vehicles, and hybrid vehicles.
[0033] In some embodiments, the diagnostic device can communicate with the target vehicle via wired or wireless means. For example, the diagnostic device can be connected to the target vehicle's on-board diagnostic interface (OBD interface) to obtain diagnostic information stored in its internal electronic control unit (ECU), or a wireless connection can be established with the vehicle to obtain relevant diagnostic information.
[0034] Diagnostic information is a collection of data that diagnostic equipment acquires and parses from a target vehicle, reflecting the vehicle's operating status and fault conditions. For example, diagnostic information may include, but is not limited to, Diagnostic Trouble Codes (DTCs), fault occurrence time, fault frequency, relevant sensor readings, control unit status, and historical maintenance records.
[0035] A component is an electronic control unit or subsystem that has a fault code when the diagnostic equipment scans the target vehicle. For example, components may include, but are not limited to, the engine control module (ECM), the transmission control module (TCM), the battery management system (BMS), the camera module of the advanced driver assistance system (ADAS), and the airbag control unit.
[0036] Diagnostic results are specific output information obtained after performing a diagnostic operation (such as an initial scan operation) on a component. For example, diagnostic results may include, but are not limited to, whether the component has a current fault, whether there are historical faults, the severity level of the fault, the associated fault description text, and the freeze frame data when the fault occurred.
[0037] In some embodiments, a diagnostic request (such as a read DTC command) instruction can be sent by a diagnostic device to the electronic control unit or control system where the corresponding component is located, and the diagnostic result of the component can be obtained by parsing the raw data returned by the device.
[0038] In some embodiments, diagnostic request commands can be sent to multiple components of the target vehicle through a diagnostic device, and the returned response data can be received to obtain diagnostic information of the target vehicle.
[0039] Step 220: In response to the triggering operation of the target component in the component, if the diagnostic result of the target component includes the target fault code, process the target fault code according to the language model to obtain the repair feasibility corresponding to the target fault code.
[0040] A trigger operation is an interactive operation performed by a user on a specific component or its diagnostic results on the user interface of a diagnostic device. For example, trigger operations may include, but are not limited to, clicking, touching, long pressing, voice commands, gesture recognition, etc. In some embodiments, the user's intention to view detailed information about a component can be obtained through the input module (such as a touch screen, button, microphone) of the diagnostic device, and used as a trigger operation for the target component among the faulty components.
[0041] The target component is the component selected by the user through a triggered action that requires further analysis. For example, the target component may include, but is not limited to, any one or more of the multiple components currently displayed on the interface.
[0042] In some embodiments, after the diagnostic device establishes a connection with the target vehicle, a diagnostic main interface is displayed. The user can select an item on the diagnostic main interface to determine the target component, or the diagnostic terminal can recommend a target component based on a preset priority and select it after user confirmation.
[0043] A target fault code is a code in the diagnostic results that indicates a specific type of fault. For example, target fault codes may include, but are not limited to, P0171 (system too sparse).
[0044] Repair feasibility is a judgment result based on the repair attribute characteristics of the target fault code and the current scenario information, indicating whether effective repair can be performed under the current scenario information. For example, repair feasibility may include, but is not limited to, the ability to perform static calibration immediately, the need for calibration under dynamic driving conditions, the current environment not meeting the calibration site requirements, and the ability to perform ECU online programming.
[0045] A language model is a machine learning model trained using large amounts of text data, based on deep learning techniques. For example, a language model can be a Large Language Model (LLM). Exemplary large language models include, but are not limited to, BERT (Bidirectional Encoder Representation from Transformers), GPT (Generative Pre-Trained Transformer), XL-Net, and ChatGLM-6B.
[0046] In some embodiments, a language model can be used to perform semantic understanding of target fault codes, vehicle information, etc., to determine their corresponding repair conditions, and combined with scenario information such as the geographical location of the diagnostic equipment, real-time weather conditions, equipment connectivity, and user permission level, to perform reasoning and judgment to determine the feasibility of repair.
[0047] Step 230: Based on repair feasibility, determine the diagnostic function interaction element corresponding to the target vehicle under the target fault code. The diagnostic function interaction element is associated with the fault indicated by the target fault code.
[0048] Diagnostic function interactive elements are operation controls in the user interface of a diagnostic device used to trigger diagnostic or repair operations related to fault handling. For example, diagnostic function interactive elements may include, but are not limited to, interactive components such as buttons, menu items, hyperlinks, toggle controls, or icons. Exemplary examples include, but are not limited to, controls for clearing fault codes, starting a test, viewing repair guidance documents, recommending replacement parts lists, refreshing program functions, and viewing frozen frames.
[0049] In some embodiments, diagnostic function interaction elements can be determined in a variety of ways. For example, based on the determination result of repair feasibility, interaction elements that match the determination result of repair feasibility can be dynamically called from a local or cloud-based function template library. Diagnostic function interaction elements can be configured to be clickable or non-clickable, thereby ensuring that currently executable operation options are presented to the user and avoiding invalid or erroneous operations.
[0050] Step 240: Based on the diagnostic function interactive elements, display the target diagnostic interface corresponding to the repair feasibility.
[0051] The target diagnostic interface is a visual display area on the diagnostic device used to present operation options related to the target fault code to the user. For example, the target diagnostic interface may include, but is not limited to, a pop-up details page corresponding to the target fault code, a column display window, a full-screen diagnostic guidance page, a collapsible information panel, etc.
[0052] For example, the target diagnostic interface may be at least one of the following: a text area displaying fault details, a chart control displaying data, a function space for performing operations, a pop-up message for prompting, and a wizard-style page guiding the user through the maintenance process.
[0053] In some embodiments, the target diagnostic interface can be generated and displayed in various ways. For example, the determined diagnostic function interaction elements can be arranged and combined according to a preset user interface layout to form the target diagnostic interface. For instance, when repair feasibility is calibrable or programmable, operation buttons such as "Start Calibration" or "Execute Programming" are displayed, and related function controls are enabled. When repair feasibility is not repairable, a prompt interface containing necessary environmental information (such as dynamic calibration on a flat, dry surface) is displayed, and related non-executable function controls are disabled. Optionally, auxiliary diagnostic functions such as "View Data Stream" can also be provided. When repair feasibility requires hardware replacement, a guide interface containing recommended accessory models, supplier information, and purchase links is displayed, and the target diagnostic interface is presented to the user through the diagnostic device's display screen.
[0054] In some embodiments of this application, by introducing a language model to parse the target fault code, the problem that traditional diagnostic systems can only provide a standardized diagnostic interface can be overcome, enhancing the comprehensibility and practicality of the diagnostic results. At the same time, by enabling maintenance feasibility, the dynamic configuration of the interactive elements of the diagnostic function can be achieved, which helps to personalize the content of the diagnostic interface and contextualize its functions, thereby improving the intelligence level of the diagnostic system. This effectively reduces the user's search cost in complex menus and improves the human-computer interaction efficiency and ease of operation of the diagnostic equipment.
[0055] In some embodiments, the method further includes: If the diagnostic results for the target component do not include the target fault code, the default component general interface is displayed.
[0056] The component general interface is an interactive page displayed by the diagnostic device when there is no specific fault code in the target component. It is used to provide guidance for diagnostic operations related to the target component.
[0057] For example, the general interface of a component may include, but is not limited to, the functional description text of the component, the recommended inspection process list, and common maintenance precautions. The general interface of a component may also include the traditional interactive interface corresponding to the component, such as functional components that include ECU version reading, fault code reading, fault code clearing, data stream reading, IO testing, configuration code writing, and firmware flashing.
[0058] In some embodiments, the common interface for components can be determined in various ways. For example, based on the type of the target component (such as an engine control module), the corresponding static page can be loaded from a pre-stored interface template library on the diagnostic device to obtain a preset common interface for components. For example, the preset common interface for components may include, but is not limited to, a troubleshooting guidance interface for the engine system, a communication status viewing interface for the body control module, and a data flow monitoring interface for sensor components.
[0059] In addition, the component's general interface can also integrate a set of general diagnostic function interaction elements applicable to this type of component, such as the "Read Real-Time Data Stream" control, the "Execute Active Test" control, the "View Communication Status Graph" control, and the "Reset Control Unit" control.
[0060] In some embodiments of this application, by displaying a preset component general interface when there is no target fault code, the robustness and usability of the diagnostic system are improved, continuous operation guidance can be provided to maintenance personnel, and the probability of misjudgment and repeated testing can be reduced.
[0061] In some embodiments, the target fault code is processed according to a language model to obtain the repair feasibility corresponding to the target fault code, including: Obtain vehicle information and current scene information of the target vehicle. The current scene information includes at least one of the following: geographic information, environmental information, and device information of the target vehicle. Based on vehicle information and the target fault code, the target repair conditions corresponding to the target fault code are determined using a language model. Determine whether the current scenario information meets the target repair conditions corresponding to the target fault code, in order to determine the repair feasibility corresponding to the target fault code; The target maintenance conditions include at least one of the following: Does the geographic information meet the target road conditions? Does the environmental information meet the target environmental conditions? Does the user's identity information match the target user's identity information? Does the equipment information match the target equipment information?
[0062] Vehicle information is data that reflects the attributes and configuration of a target vehicle. For example, vehicle information may include, but is not limited to, the Vehicle Identification Number (VIN), vehicle brand, model, production year, engine model, transmission type, hardware version of the Electronic Control Unit (ECU), current firmware version number, and in-vehicle network topology.
[0063] Current scenario information reflects the environment in which the target vehicle is located at the time of diagnosis. For example, current scenario information may include, but is not limited to, the geographical location of the target vehicle, the temperature, humidity and pressure of the surrounding environment, the model of the diagnostic equipment, user authentication information, network connection status, power supply stability and other information.
[0064] Geographic information is descriptive data about the current geographical location of a target vehicle. Geographic information can be used to determine whether it is in a road or area environment suitable for performing a specific maintenance operation. For example, geographic information may include, but is not limited to, latitude and longitude coordinates, altitude, road type (highway, urban road, mountain bend), whether it is within the coverage area of a maintenance station, and whether it is in a signal blind spot.
[0065] Environmental information refers to the state parameters of the physical environment surrounding the target vehicle. For example, environmental information may include, but is not limited to, ambient temperature, relative humidity, atmospheric pressure, and light intensity.
[0066] Device information refers to relevant information about electronic devices currently being used for diagnostics or about to be involved in repair operations. For example, device information may include, but is not limited to, the model of the diagnostic device, firmware version, whether it has programming / refreshing capabilities, whether it has a high voltage protection level, and whether it is connected to a dedicated testing tool (such as an oscilloscope or battery tester).
[0067] Target maintenance conditions are the conditions that must be met for maintenance operations recommended or required for a specific fault code.
[0068] Among them, target road conditions are the specific requirements that geographic information should meet in the target maintenance conditions. For example, target road conditions may include, but are not limited to, level and stationary road surfaces, prohibition on slopes, in closed test areas, and prohibition on high-speed driving.
[0069] In some embodiments, the target road conditions can be obtained in a variety of ways. For example, the corresponding road requirements can be extracted from the maintenance manual based on the fault type (such as those involving the braking system or power output), or the road conditions applicable to the target fault code can be generated by the language model based on historical maintenance cases.
[0070] Target environmental conditions are the specific requirements set for the surrounding physical environment in the target maintenance conditions. For example, target environmental conditions may include, but are not limited to, meeting a preset temperature range, meeting a preset humidity range, and having no risk of rainfall or water accumulation. In some embodiments, target environmental conditions can be obtained in various ways, such as extracting corresponding environmental requirement information from the maintenance manual based on the fault type (e.g., involving the braking system or power output); or generating environmental constraint information applicable to the target fault code by a language model based on historical maintenance cases.
[0071] The target user identity information refers to the category of personnel qualifications or permissions that are allowed to perform a certain maintenance operation as specified in the target maintenance conditions. For example, the target user identity information may include, but is not limited to, the target administrator account.
[0072] Target device information refers to the specific model, function, or configuration requirements of the diagnostic or repair tools needed to perform the repair tasks, as specified in the target repair conditions. Target device information may include, but is not limited to, the existence of a target toolkit or firmware package.
[0073] In some embodiments, a corresponding judgment model can be trained based on a language model to determine the repair feasibility corresponding to the target fault code. The input to the judgment model can be the target fault code, current scenario information, and vehicle information of the target vehicle, and the output can be the judgment result of repair feasibility.
[0074] In some embodiments, a pre-trained model can be obtained, and fine-tuning training can be performed on the pre-trained model to obtain a judgment model.
[0075] In some embodiments, the pre-trained model can be a language model or a large language model obtained through a pre-training phase.
[0076] The pre-training phase refers to the stage of training a language model on large-scale data using unsupervised learning methods.
[0077] In some embodiments, the pre-trained model can be a language model or a large language model pre-trained on a pre-trained dataset. The pre-trained dataset can be a general-purpose text corpus. It can consist of numerous text sources, including books, articles, and websites. This data is carefully curated to ensure a comprehensive reflection of human knowledge, linguistic nuances, and cultural perspectives. Pre-trained datasets are typically large-scale datasets containing rich features and samples.
[0078] Pre-trained models are suitable for a variety of scenarios. In practical applications, fine-tuning the training can yield language models or large language models that are specifically designed for a particular task.
[0079] In some embodiments, existing pre-trained models can be obtained directly from the network. For example, BERT, GPT, or XLNet can be used as pre-trained models.
[0080] In some embodiments, a pre-trained model can be used as the initial judgment model. For example, GPT can be trained using pre-training data, and techniques such as supervised fine-tuning, feedback self-help, and human feedback reinforcement learning can be used to further improve GPT's language expression capabilities.
[0081] In some embodiments, a diagnostic text training corpus can be constructed, and the initial judgment model can be fine-tuned to determine the judgment model.
[0082] A diagnostic text training corpus refers to an information repository that includes text data related to diagnosis. In some embodiments, the diagnostic text training corpus may include sample diagnostic text data (i.e., training samples) and their corresponding judgment results (i.e., training labels). In some embodiments, the diagnostic text training corpus may be constructed based on historical diagnostic data and the judgment results corresponding to historical diagnostic text data. In some embodiments, the judgment results corresponding to the sample diagnostic text data may be determined by human annotation.
[0083] In some embodiments, the acquired historical diagnostic data can be cleaned. Data cleaning removes unnecessary data from the collected diagnostic data. Data cleaning may include removing privacy information, removing useless labels, removing duplicate data, and removing erroneous data. Data cleaning makes the data in the diagnostic text training corpus more standardized, clean, complete, and reliable.
[0084] In some embodiments, the acquired historical diagnostic data can be integrated and standardized. Data integration can combine several data sources with different formats, names, and origins into a unified dataset. Data integration methods include table fusion, feature fusion, parallel data processing, collaborative filtering, etc. Data standardization can uniformly standardize several data sources with different formats, names, and origins. In some embodiments, data standardization includes metadata management, data naming rules, data type and format control, etc. Format control can unify the format of the corpus data after data cleaning.
[0085] In some embodiments, when constructing a diagnostic text training corpus, the completeness of the corpus can be ensured as much as possible (such as whether the text content is complete, whether the sentences are complete, data indexes, etc.).
[0086] In some embodiments, the pre-trained model obtained in the aforementioned manner can be used as the initial judgment model.
[0087] In some embodiments, the initial judgment model can be fine-tuned using various fine-tuning strategies to determine the final judgment model. For example, fine-tuning strategies include adaptive fine-tuning and multi-task learning. Fine-tuning training refers to the training phase in which a pre-trained language model is fine-tuned based on a specific task using supervised learning methods.
[0088] Supervised learning methods refer to training methods where a language model that has undergone a pre-training phase is trained on labeled data for a specific task.
[0089] In some embodiments, the initial judgment model can be trained using various methods based on multiple labeled training samples to update its parameters, thus obtaining the judgment model. For example, it can be trained using gradient descent. As an example only, multiple labeled sample diagnostic text data can be input into the initial judgment model. A loss function can be constructed using the labels and the output of the initial judgment model. The parameters of the initial judgment model are then iteratively updated based on the loss function. The model training is complete when the loss function of the initial judgment model meets preset conditions, resulting in a trained judgment model. These preset conditions could include loss function convergence, the number of iterations reaching a threshold, etc.
[0090] In some embodiments, the judgment model may include a preprocessing layer and a judgment layer. The input to the preprocessing layer may be a target fault code or vehicle information from diagnostic data, and the output may be the target repair condition corresponding to the target fault code. The input to the judgment layer may be the target repair condition and current scenario information, and the output may be the judgment result. In some embodiments, the preprocessing layer may be a first language model. In some embodiments, the judgment layer may be a second language model. The first language model may be the same as or different from the second language model.
[0091] In some embodiments, the decision layer can be obtained through pre-training followed by fine-tuning. See the preceding descriptions for further details.
[0092] In some embodiments of this application, by adapting and fine-tuning a diagnostic text training corpus based on an existing language model (such as GLM-130B), the feasibility of repair corresponding to a target fault code can be effectively determined from diagnostic text data by utilizing context learning capabilities.
[0093] In some embodiments, based on diagnostic function interactive elements, a target diagnostic interface corresponding to repair feasibility is displayed, including: If the current scenario information meets the target repair conditions, and the repair feasibility is determined to be repairable, then the target diagnostic interface is displayed based on the diagnostic function interactive elements; or; If the current scenario information does not meet the target repair conditions, the repair feasibility is determined to be unrepairable, and the general repair interface for the target fault code is displayed. The general repair interface for the fault code includes the repair guidance materials corresponding to the target fault code.
[0094] The general troubleshooting interface for fault codes is an interface displayed by diagnostic equipment when the fault code is not repairable, providing general information and auxiliary guidance related to the target fault code.
[0095] In some embodiments, the general fault code repair interface does not include executable operation controls. For example, the general fault code repair interface may include, but is not limited to, fault descriptions of the target fault code, a list of possible causes of the fault, documentation of recommended repair steps, a list of required special tools, standard repair flowcharts, links to relevant Technical Service Bulletins (TSBs), and geographical location information of recommended repair locations, as well as other repair guidance materials.
[0096] In some embodiments, maintenance guidance information can be obtained in various ways. For example, diagnostic equipment can download information by matching the target fault code with vehicle information in the database of a third-party service platform (such as a maintenance information service platform), or extract relevant content from a locally pre-installed offline maintenance manual.
[0097] In some embodiments of this application, by presenting currently executable functional controls, the diagnostic interface is simple and intuitive, and the operation path is clear, reducing the user's time cost and operation threshold, which is conducive to non-professional users or junior technicians to efficiently complete complex repair tasks.
[0098] In some embodiments, the diagnostic function interaction elements include at least one of the following: a fault code reading control, a fault code clearing control, a data stream control, a test function control, a special function control, a calibration function control, and a write function control.
[0099] The fault code read control is an interactive element used to trigger diagnostic equipment to send a request to the electronic control unit of the target vehicle to retrieve stored fault information.
[0100] The Clear Fault Code control is an interactive element used to trigger diagnostic equipment to send instructions to the electronic control unit of the target vehicle to clear stored fault codes and related freeze frame data.
[0101] The data flow control is an interactive element used to trigger diagnostic equipment to read and display the internal parameters of the electronic control unit of the target vehicle in real time.
[0102] Test function controls are interactive elements used to trigger diagnostic equipment to perform functional tests on specific systems or components.
[0103] Special function controls are functional elements used to trigger non-standard diagnostic operations related to specific vehicle models or systems.
[0104] The calibration function control is an interactive element used to trigger diagnostic equipment and guide the user through the sensor or system calibration process.
[0105] The flashing function control is an interactive element used to trigger diagnostic equipment to update the firmware or software of a target electronic control unit (ECU).
[0106] In some embodiments, the diagnostic function interaction elements corresponding to the target vehicle under the target fault code are determined based on repair feasibility, including: When repairable, based on the mapping relationship between preset fault codes and preset diagnostic function interaction elements, and the target fault code, determine the diagnostic function interaction element that matches the target fault code.
[0107] The mapping relationship between preset fault codes and preset diagnostic function interaction elements can be determined based on historical data or prior knowledge.
[0108] In some embodiments of this application, when the fault is confirmed to be repairable, diagnostic functions and guidance content directly related to the fault can be accurately pushed, avoiding irrelevant functions from interfering with user decision-making and improving diagnostic efficiency and operational accuracy.
[0109] In some embodiments, when the target fault code is a calibration type fault code, the diagnostic function interaction element matching the target fault code includes at least a calibration function control; or When the target fault code is a software type fault code, the diagnostic function interaction elements that match the target fault code must include at least a flash function control.
[0110] Calibration-type fault codes are those triggered by sensors or systems failing to complete calibration, resulting in inaccurate sensing or output data. Examples of calibration-type fault codes include, but are not limited to, camera calibration failure, radar sensor angle deviation, electronic power steering system steering angle sensor not initialized, and lane keeping system calibration loss.
[0111] When the target fault code is a calibration type fault code, the diagnostic function interaction elements that match the target fault code should at least include calibration function controls, and may also include clear fault code controls, data flow controls, etc.
[0112] Software-related fault codes may include, but are not limited to, incompatible software versions, incomplete ECU programming, failed safety module authentication, or incompatible gateway communication protocol versions.
[0113] When the target fault code is a software type fault code, the diagnostic function interaction elements that match the target fault code should at least include a write function control, and may also include a clear fault code control, a data flow control, etc.
[0114] It should be noted that the above description of the process is for illustrative purposes only and does not limit the scope of this specification. Those skilled in the art can make various modifications and changes to the process under the guidance of this specification. However, these modifications and changes remain within the scope of this specification.
[0115] To better understand the above solution, the diagnostic interface display method will be explained below with a specific embodiment.
[0116] After establishing a connection with the target vehicle, the diagnostic equipment communicates with the vehicle's electronic control unit (ECU) via the On-Board Diagnostic Interface (OBD-II). It then broadcasts diagnostic requests to each ECU, scans and reads fault information stored in each ECU, and obtains diagnostic results including fault codes (DTCs), freeze frame data, and system status flags. The diagnostic equipment analyzes the obtained diagnostic results to determine if there are any currently valid fault codes. If no fault codes are detected, a preset traditional diagnostic interface categorized by system is displayed on the screen. This traditional diagnostic interface displays a list of scanned vehicle control systems. Users can click on a vehicle control system to select and enter the preset component general interface for that vehicle control system.
[0117] If at least one fault code exists in the target vehicle, generate and display a fault code list interface (such as...). Figure 3 As shown in the diagram, the fault code list interface summarizes and displays fault code entries read from each electronic control unit (ECU) of the target vehicle. If no fault codes are found in the ECU of the target vehicle, the general interface of the corresponding components for that ECU is displayed in response to a trigger operation on the ECU. Figure 4 As shown.
[0118] In response to a user's triggering action on a specific fault code in the fault code list interface, the system enters the corresponding diagnostic sub-interface. Here, a language model can be used to analyze the fault type indicated by the fault code and vehicle information to obtain the corresponding target repair conditions. Combining the obtained geographical location information, environmental information, diagnostic equipment functional status, and user permission information of the target vehicle, the system determines the target repair conditions that the current scenario information corresponding to the fault code must meet. Based on the judgment result of the current scenario information and the target repair conditions, the system determines the repair feasibility of the fault code.
[0119] If the repair feasibility is deemed feasible, identify the diagnostic function interaction element matching the fault code. This element includes functional controls related to the fault type. For example, in the case of a fault code indicating camera calibration failure, and given that the repair feasibility is deemed feasible, the corresponding diagnostic function interaction element would at least include calibration function controls (such as...). Figure 5 As shown); based on the determined diagnostic function interaction elements, a target diagnostic interface is generated and displayed. The target diagnostic interface contains an operable calibration guide menu to enable users to start the ADAS static calibration or dynamic calibration process, and displays data stream information such as camera angle and calibration status in real time during the operation.
[0120] When a repair is deemed unfeasible, a general repair interface for the fault code is generated and displayed. This interface does not contain any executable function controls but presents repair guidance information related to the fault code. For example, if the fault code indicates camera calibration failure, but the current ambient lighting is insufficient or the location is in an underground parking garage, the general repair interface will display the message "Current environment does not meet calibration conditions," along with the required standard site requirements, recommended environmental parameters, and subsequent operational suggestions.
[0121] When the user completes the calibration operation and exits the diagnostic sub-interface corresponding to the fault code, the diagnostic equipment rescans the fault information of the target vehicle to determine whether the fault code still exists: if the scan result shows that the fault code has been cleared, the fault code entry is removed from the fault code list interface; if all fault codes are cleared, a prompt message "The vehicle has no current fault codes" is generated, and the system automatically returns to the traditional diagnostic interface categorized by system.
[0122] For example, in the case of an ECU incompatibility fault code, in response to the triggering operation of the fault code, it is determined whether the current scenario information can be used to perform online programming on the target ECU; if the determination result is programmable, a flashing function control is provided to guide the user to perform a firmware update; if the determination result is not programmable, a repair guidance interface is generated and displayed, which includes the recommended replacement ECU model, compatibility instructions, and information on parts purchase channels recommended based on geographical location.
[0123] After the user completes the programming operation or views the replacement suggestion and exits the diagnostic sub-interface corresponding to the fault code, the diagnostic equipment rescans the fault information of the target vehicle to determine whether the fault code still exists: if the scan result shows that the fault code has been cleared, the fault code entry is removed from the fault code list interface; if all fault codes are cleared, a prompt message "The vehicle has no current fault codes" is generated, and the system automatically returns to the traditional diagnostic interface categorized by system.
[0124] Figure 6 This is an exemplary schematic diagram of a diagnostic interface display device provided in some embodiments of this application.
[0125] like Figure 6 As shown in the diagram, one or more embodiments of this specification also provide a structural schematic of a diagnostic interface display device. This diagnostic interface display device may include: The diagnostic module 601 is used to display the diagnostic information of the target vehicle diagnosed by the diagnostic device, the diagnostic information including the diagnostic results of at least one component in the target vehicle; The judgment module 602 is used to respond to the trigger operation of the target component in the component, and when the diagnostic result of the target component includes the target fault code, it processes the target fault code according to the language model to obtain the repair feasibility corresponding to the target fault code. The determination module 603 is used to determine the diagnostic function interaction element corresponding to the target vehicle under the target fault code based on repair feasibility. The diagnostic function interaction element is associated with the fault indicated by the target fault code. Display module 604 is used to display the target diagnostic interface corresponding to the repair feasibility based on the diagnostic function interactive elements.
[0126] The diagnostic module 601, judgment module 602, determination module 603, and display module 604 can be used to execute the embodiments corresponding to the above-mentioned diagnostic interface display method. For the specific implementation methods of these modules and more details, please refer to the corresponding method section, which will not be elaborated here.
[0127] For details on the implementation of each of the above operations, please refer to the previous examples, which will not be repeated here.
[0128] Figure 7 These are exemplary schematic diagrams of electronic devices provided in some embodiments of this application.
[0129] This application also provides an electronic device 700, which may include components such as a processor 701 with one or more processing cores, a memory 702 with one or more computer-readable storage media, a power supply 703, and an input unit 704. Those skilled in the art will understand that... Figure 7 The electronic device structure shown does not constitute a limitation on the electronic device and may include more or fewer components than shown, or combine certain components, or have different component arrangements. Wherein: The processor 701 is the central display of the diagnostic interface. It connects various parts of the electronic device via various interfaces and lines. By running or executing software programs and / or modules stored in the memory 702, and by calling data stored in the memory 702, it performs various functions and processes data of the electronic device, thereby providing overall monitoring of the electronic device. It is understood that the processor 701 communicates with the controller via signal transmission. Optionally, the processor 701 may include one or more processing cores; preferably, the processor 701 may integrate an application processor and a modem processor. The application processor primarily handles the operating system, user interface, and applications, while the modem processor primarily handles wireless communication. It is understood that the aforementioned modem processor may also not be integrated into the processor 701.
[0130] The memory 702 can be used to store software programs and modules. The processor 701 executes various functional applications and data processing by running the software programs and modules stored in the memory 702. The memory 702 may mainly include a program storage area and a data storage area. The program storage area may store the operating system, application programs required for at least one function (such as sound playback function, image playback function, etc.), etc.; the data storage area may store data created according to the use of the electronic device, etc. In addition, the memory 702 may include high-speed random access memory, and may also include non-volatile memory, such as at least one disk storage device, flash memory device, or other volatile solid-state storage device. Accordingly, the memory 702 may also include a memory controller to provide the processor 701 with access to the memory 702.
[0131] In some embodiments of this application, the diagnostic interface display device can be implemented as a computer program, and the computer program can be implemented as follows: Figure 7 The device operates on the electronic device shown. The memory of the electronic device can store various program modules that make up the diagnostic interface display device. The computer program composed of the various program modules causes the processor to execute the steps in the diagnostic interface display methods of the various embodiments of this application described in this specification.
[0132] The electronic device also includes a power supply 703 that supplies power to the various components. Preferably, the power supply 703 is logically connected to the processor 701 through a power management system, thereby enabling functions such as charging, discharging, and power consumption management through the power management system. The electronic device may also include an input unit 704, which can be used to receive input digital or character information and generate keyboard, mouse, joystick, optical, or trackball signal inputs related to user settings and function control.
[0133] Although not shown, electronic devices may also include display units, etc., which will not be described in detail here.
[0134] In practice, each of the above units or structures can be implemented as an independent entity or can be arbitrarily combined to be implemented as the same or several entities. For the specific implementation of each of the above units or structures, please refer to the previous method embodiments, which will not be repeated here.
[0135] It should be noted that, Figure 7 This is merely one implementation of the electronic device 700 provided in this application embodiment. In actual applications, the electronic device 700 may include more or fewer components, which is not limited here.
[0136] It should also be understood that, in the various embodiments of this application, the order of the above-mentioned processes does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.
[0137] Based on the above embodiments and the same concept, this application also provides a computer-readable storage medium storing a computer program that, when run on a computer, causes the computer to perform the method provided in the above embodiments.
[0138] Based on the above embodiments and the same concept, this application also provides a computer program product, which includes a computer program that, when run on a computer, causes the computer to execute the method provided in the above embodiments.
[0139] In the description of this application, 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. Therefore, a feature defined as "first" or "second" may explicitly or implicitly include one or more features. In the description of this application, "multiple" means two or more, unless otherwise explicitly specified.
[0140] The embodiments, implementation methods, and related technical features of this application can be combined and substituted for each other without conflict.
[0141] The above are merely preferred embodiments of this application and are not intended to limit this application in any way. Although the descriptions of each embodiment in this application have different focuses, and the parts not described in detail in a certain embodiment can be referred to the relevant embodiments of other embodiments, any simple modifications, equivalent changes and modifications made to the above embodiments based on the technical essence of this application without departing from the content of the technical solution of this application shall still fall within the scope of the technical solution of this application.
Claims
1. A diagnostic interface display method, characterized in that, Applied to diagnostic devices, the method includes: The diagnostic information of the target vehicle diagnosed by the diagnostic device is displayed, and the diagnostic information includes the diagnostic results of at least one component in the target vehicle. In response to a triggering operation on a target component in the components, if the diagnostic result of the target component includes a target fault code, the target fault code is processed according to a language model to obtain the repair feasibility corresponding to the target fault code; Based on the repair feasibility, determine the diagnostic function interaction element corresponding to the target vehicle under the target fault code, and the diagnostic function interaction element is associated with the fault indicated by the target fault code; Based on the diagnostic function interactive elements, the target diagnostic interface corresponding to the repair feasibility is displayed.
2. The method according to claim 1, characterized in that, The method further includes: If the diagnostic results for the target component do not include the target fault code, a preset general interface for the component is displayed.
3. The method according to claim 1, characterized in that, The step of processing the target fault code according to the language model to obtain the repair feasibility corresponding to the target fault code includes: Obtain vehicle information of the target vehicle and current scene information of the target vehicle, wherein the current scene information includes at least one of the geographical information, environmental information and equipment information of the target vehicle. Based on the vehicle information and the target fault code, the target repair conditions corresponding to the target fault code are determined using a language model. Determine whether the current scenario information meets the target maintenance conditions corresponding to the target fault code, so as to determine the maintenance feasibility corresponding to the target fault code; The target maintenance conditions include at least one of the following conditions: Does the geographic information meet the target road conditions? Does the environmental information meet the target environmental conditions? Does the user's identity information match the target user's identity information? Does the device information match the target device information? 4. The method according to claim 3, characterized in that, The target diagnostic interface corresponding to the repair feasibility is displayed based on the diagnostic function interaction elements, including: If the current scenario information meets the target repair conditions, the repair feasibility is determined to be repairable, and the target diagnostic interface is displayed based on the diagnostic function interaction elements; or; If the current scenario information does not meet the target repair conditions, the repair feasibility is determined to be unrepairable, and the general repair interface for the target fault code is displayed. The general repair interface for the fault code includes the repair guidance materials corresponding to the target fault code.
5. The method according to claim 1, characterized in that, The diagnostic function interactive elements include at least one of the following: read fault code control, clear fault code control, data stream control, test function control, special function control, calibration function control, and write function control.
6. The method according to claim 1, characterized in that, The step of determining the diagnostic function interaction elements corresponding to the target vehicle under the target fault code based on the repair feasibility includes: In the case of repairability, based on the mapping relationship between preset fault codes and preset diagnostic function interaction elements, and the target fault code, a diagnostic function interaction element matching the target fault code is determined.
7. The method according to claim 6, characterized in that, When the target fault code is a calibration type fault code, the diagnostic function interaction element matching the target fault code includes at least a calibration function control; or When the target fault code is a software type fault code, the diagnostic function interaction element matching the target fault code includes at least a write function control.
8. A diagnostic interface display device, characterized in that, The device includes: A diagnostic module is used to display diagnostic information of a target vehicle diagnosed by a diagnostic device, the diagnostic information including the diagnostic results of at least one component in the target vehicle; The judgment module is used to respond to a trigger operation on a target component in the components, and when the diagnostic result of the target component includes a target fault code, to process the target fault code according to a language model to obtain the repair feasibility corresponding to the target fault code. The determination module is used to determine, based on the repair feasibility, the diagnostic function interaction element corresponding to the target vehicle under the target fault code, wherein the diagnostic function interaction element is associated with the fault indicated by the target fault code; The display module is used to display the target diagnostic interface corresponding to the repair feasibility based on the diagnostic function interactive elements.
9. An electronic device, characterized in that, include: A memory on which computer programs are stored; A processor for executing the computer program in the memory to implement the steps of the method according to any one of claims 1 to 7.
10. A computer-readable storage medium, characterized in that, It stores a computer program thereon, which, when executed by a processor, implements the steps of the method according to any one of claims 1 to 7.