Vehicle diagnostic report generation methods, devices, electronic equipment, and storage media

Abstract

This application provides a method, apparatus, electronic device, and storage medium for generating vehicle diagnostic reports. The method includes: calling diagnostic software to obtain diagnostic report requirements, vehicle information, and vehicle fault codes, wherein the diagnostic report requirements indicate the diagnostic report to be issued; determining the corresponding functional plug-in from a plug-in library based on the vehicle information, the plug-in library including functional plug-ins for different vehicle models; determining the On-Board Diagnostic (OBD) protocol, parameter identifier (PID) list, and acquisition strategy from the functional plug-in using the vehicle fault codes; accessing the vehicle's OBD interface based on the OBD protocol and obtaining first data of the vehicle based on the PID list and acquisition strategy; mapping the first data into readable fields based on the functional plug-in to obtain second data; and generating a diagnostic report based on the functional plug-in, the diagnostic report requirements, and the second data. This improves the efficiency of diagnostic report generation.

Description

Technical Field

[0001] This application relates to the field of vehicle diagnostic technology, and in particular to a method, apparatus, electronic device and storage medium for generating vehicle diagnostic reports. Background Technology

[0002] Modern automobiles are generally equipped with a standardized second-generation On-Board Diagnostics II (OBD-II) interface, which can output fault codes (DTCs) and a wealth of real-time data streams (such as engine load, oxygen sensor voltage, etc.). Most mainstream automotive diagnostic equipment uses dedicated applications developed based on the Android system, communicating with the vehicle via Bluetooth or a USB-OBD adapter. However, current automotive diagnostic equipment still heavily relies on manual operation by technicians when generating professional diagnostic reports, resulting in low efficiency. Summary of the Invention

[0003] This application provides a method, apparatus, electronic device, and storage medium for generating vehicle diagnostic reports. By using an intelligent agent, the diagnostic process is automated, thereby improving the efficiency of diagnostic report generation.

[0004] Firstly, this application provides a method for generating a vehicle diagnostic report, which is applied to an intelligent agent and includes: The diagnostic software is invoked to obtain diagnostic report requirements, vehicle information, and vehicle fault codes. The diagnostic report requirements indicate the diagnostic report that needs to be issued. Based on vehicle information, the plugins corresponding to the vehicle information are determined from the plugin library, which includes plugins for different vehicle models. The vehicle fault codes are used to determine the On-Board Diagnostic (OBD) protocol, parameter identifier (PID) list, and acquisition strategy from the functional plug-in. Access the vehicle's OBD interface based on the OBD protocol, and obtain the vehicle's first data based on the PID list and acquisition strategy; The second data is obtained by mapping the first data into readable fields based on the functional plugin; Diagnostic reports are generated based on functional plugins, diagnostic report requirements, and second data.

[0005] As can be seen, in this application, by replacing the traditional manual operation of technicians with an intelligent agent, and by utilizing the pre-built functional plugins for different vehicle models in the plugin library, the standardized adaptation of diverse vehicle information is achieved, solving the problem of poor standardization in the diagnostic process. By reverse-engineering the vehicle fault codes to determine the accurate PID list and collection strategy, on-demand triggering and data collection are achieved, avoiding invalid data scanning and improving the efficiency of diagnostic report generation. Based on the functional plugins, the underlying first data is mapped into readable fields to obtain the second data, eliminating the error of manual interpretation of the data stream and ensuring the reliability of the data. Thus, high-efficiency, high-reliability vehicle diagnosis without human intervention can be achieved.

[0006] In a feasible example, the functional plug-in includes an OBD communication adapter and a data acquisition strategy lookup table. The OBD communication adapter defines the OBD protocols supported by the corresponding vehicle model for the functional plug-in. The data acquisition strategy lookup table defines the list of PIDs to be read and the acquisition strategy for different fault codes. The corresponding on-board diagnostic system OBD protocol, PID list, and acquisition strategy are determined from the functional plug-in based on the vehicle fault codes, including: Determine the OBD protocol based on the OBD communication adapter; Based on the vehicle fault codes, the matching PID list and acquisition strategy are determined from the acquisition strategy lookup table.

[0007] In this application, by refining the functional plug-in into an OBD communication adapter and a data acquisition strategy lookup table, the diagnostic logic is structured and modularized. The OBD communication adapter encapsulates the differences in OBD protocols supported by different vehicle models, shielding the complexity of the underlying communication protocol and solving the problem of standardization difference. The data acquisition strategy lookup table establishes a direct mapping relationship between fault codes, PID lists, and acquisition strategies, enabling the system to trigger data acquisition as needed based on specific fault codes, avoiding the time wasted by full scans and significantly improving diagnostic efficiency. This automated determination mechanism based on lookup tables replaces the process of technicians manually selecting parameters, eliminates human configuration errors, and ensures the accuracy and reliability of data acquisition.

[0008] In a feasible example, the functional plugin includes a data flow semantic map table, which is used to map the raw PID to readable fields. Based on the functional plugin, the first data is mapped to readable fields to obtain the second data, which includes: The first data is mapped to readable fields based on the data flow semantic mapping table in the functional plugin to obtain the second data.

[0009] In this application, a standardized semantic association between the underlying raw PID data and the upper-level readable fields is established by introducing a data flow semantic mapping table. This mapping table, as part of a functional plugin, enables the system to automatically convert the raw data returned by the vehicle into diagnostic information with clear physical meaning, eliminating the errors of manual data translation. Combined with the automated control of an AI agent, this semantic mapping mechanism ensures the accuracy and professionalism of the generated diagnostic reports.

[0010] In a feasible example, the functional plugin includes anomaly detection rules and report templates. The anomaly detection rules are used to identify anomalous data in the second set of data. Based on the functional plugin, diagnostic report requirements, and the second set of data, a diagnostic report is generated, including: The target report template is determined from the report templates based on the diagnostic report requirements; A diagnostic report is generated based on anomaly detection rules, secondary data, and the target report template.

[0011] In this application, by introducing anomaly judgment rules, the process of technicians relying on experience to identify data anomalies is transformed into automated logical judgment, eliminating subjective differences and omissions when manually analyzing data streams and solving the problem of easy errors. By using a matching mechanism between report templates and diagnostic report requirements, the standardized generation of diagnostic report format and content is achieved, avoiding the inefficiency and poor standardization caused by manual report writing. The automatic generation of diagnostic reports based on the combination of rules, data and templates ensures the professionalism and consistency of the output results.

[0012] In a feasible example, the vehicle's OBD interface is accessed based on the OBD protocol, and the vehicle's initial data is obtained based on the PID list and acquisition strategy, including: The standard interaction process corresponding to vehicle information, PID list and acquisition strategy is obtained from the interaction knowledge base, which is used to define the interaction process of the diagnostic software. Access the vehicle's OBD interface based on the OBD protocol, and execute a standard interactive process in the diagnostic software to obtain the vehicle's initial data.

[0013] In this application, interactive actions are automatically executed in the diagnostic software based on a standard interactive process, replacing the tedious operations of technicians manually clicking menus and selecting parameters, which significantly improves the efficiency of generating diagnostic reports.

[0014] In a feasible example, the method also includes: Obtain the task set and the required vehicle models. The task set includes multiple tasks, and each task includes a list of PIDs to be collected and the corresponding collection strategy. Based on the task set and the required vehicle model, the diagnostic software is used to perform task simulation and obtain the interface interaction information with the diagnostic software. Process the interface interaction information to generate standard interaction processes for each task in the task set and each vehicle model in the required vehicle models; An interactive knowledge base is built based on a vehicle model-task structure.

[0015] In this application, by transforming the captured original operation trajectory into a standard interactive process that can be executed by the machine, the uncertainty of human operation is eliminated, providing a reusable operational knowledge base for the AI ​​agent, realizing the automated recording and learning of diagnostic operation processes, and solving the problems of low efficiency and poor standardization caused by reliance on manual operation by technicians in the background technology.

[0016] In a feasible example, the standard interaction flow includes multiple consecutive sub-interaction objectives and corresponding semantic descriptions and verification conditions for each sub-objective. The standard interaction flow is executed in the diagnostic software to obtain the vehicle's initial data, including: Obtain the interface adaptation description file corresponding to the diagnostic software. The interface adaptation description file is used to define the implementation methods of page semantic acquisition operations and control matching click operations. S1. Based on the current sub-interaction goal in the standard interaction process, obtain the current page state of the operation perception diagnostic software through page semantics, and determine whether the current sub-interaction goal has been achieved based on the verification conditions of the current sub-interaction goal. S2, if not achieved, then in the set of interactive elements corresponding to the current page state, match the target control that is most relevant to the semantic description of the current sub-interaction target, and execute the interaction between the target control and the click operation through the control matching; S3, if achieved, the next sub-interaction target among multiple consecutive sub-interaction targets will be taken as the current sub-interaction target, and in the set of interactive elements corresponding to the current page state, the target control most relevant to the semantic description of the current sub-interaction target will be matched, and the interaction between the target control and the click operation will be executed through the control matching. Repeat steps S1 to S3 until the last sub-interaction goal in the standard interaction process is achieved and the first data is obtained.

[0017] In this application, the implementation method of page semantic acquisition and control matching click is defined by the interface adaptation description file, which achieves decoupling and abstraction at the interface level of the diagnostic software. The current page state of the diagnostic software is perceived through page semantic acquisition operation, and it is determined whether the current sub-interaction target has been achieved based on the verification conditions of the current sub-interaction target, ensuring the accuracy and robustness of the interaction steps. By matching the target control most relevant to the semantic description of the current sub-interaction target, the interaction between the control matching click operation and the target control is executed, replacing the process of technicians manually searching for menus and buttons, and achieving a high degree of standardization of the diagnostic process. By taking the next sub-interaction target in multiple consecutive sub-interaction targets as the current sub-interaction target, the standard interaction process is driven forward until the last sub-interaction target is achieved and the first data is obtained. This closed-loop perception, judgment and execution mechanism ensures fully automatic unmanned operation from high-level diagnostic targets to data acquisition, thereby achieving the technical effect of highly reliable automated control and end-to-end intelligent closed loop.

[0018] Secondly, this application provides a vehicle diagnostic report generation device, the device comprising: The first processing unit is used to call the diagnostic software to obtain diagnostic report requirements, vehicle information and vehicle fault codes. The diagnostic report requirements are used to indicate the diagnostic report that needs to be issued. The second processing unit is used to determine the functional plug-in corresponding to the vehicle information from the plug-in library based on the vehicle information. The plug-in library includes functional plug-ins corresponding to different vehicle models. The third processing unit is used to determine the On-Board Diagnostic System (OBD) protocol, parameter identifier PID list, and acquisition strategy from the functional plug-in through vehicle fault codes. The third processing unit is also used to access the vehicle's OBD interface based on the OBD protocol and to obtain the vehicle's first data based on the PID list and acquisition strategy. The third processing unit is also used to map the first data into readable fields based on the functional plugin to obtain the second data; The third processing unit is also used to generate diagnostic reports based on functional plugins, diagnostic report requirements, and second data.

[0019] Thirdly, this application provides an electronic device including a processor, a memory, and a communication interface. The processor, memory, and communication interface are interconnected and perform communication with each other. The memory stores executable program code, the communication interface is used for wireless communication, and the processor is used to retrieve the executable program code stored in the memory and execute some or all of the steps described in any of the methods in the first aspect.

[0020] Fourthly, this application provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements some or all of the steps described in the first aspect of this application.

[0021] Fifthly, this application provides a computer program product, including a computer program that, when processed and executed, implements some or all of the steps described in the first aspect of this application. The computer program product may be a software installation package. Attached Figure Description

[0022] To more clearly illustrate the technical solutions in the embodiments of this application 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 this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0023] Figure 1 This is a schematic diagram of the structure of a vehicle diagnostic system provided in an embodiment of this application; Figure 2 A flowchart illustrating a method for generating a vehicle diagnostic report provided in an embodiment of this application; Figure 3 A flowchart illustrating another method for generating vehicle diagnostic reports provided in this application embodiment; Figure 4 A flowchart illustrating another method for generating a vehicle diagnostic report provided in this application embodiment; Figure 5 A functional unit block diagram of a vehicle diagnostic report generation device provided in this application embodiment; Figure 6 A functional unit block diagram of another vehicle diagnostic report generation device provided in this application embodiment; Figure 7 This is a structural block diagram of an electronic device provided in an embodiment of this application. Detailed Implementation

[0024] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of the present application.

[0025] The terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish different objects, not to describe a specific order. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or apparatus that includes a series of steps is not limited to the steps listed, but may optionally include steps not listed, or may optionally include other steps inherent to these processes, methods, products, or apparatuses.

[0026] In this document, the term "embodiment" means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of this application. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

[0027] Currently, automotive diagnostic equipment generally relies heavily on manual operation when generating professional diagnostic reports. For example, technicians need to manually click on multiple steps such as "read fault codes", "clear codes", "enter data stream", "select parameters", "start reading", and "save report". The process is cumbersome, inefficient, and prone to incomplete diagnosis due to missing key operations.

[0028] Based on this, this application replaces the traditional manual operation of technicians with an intelligent agent, and uses pre-built functional plugins for different vehicle models in the plugin library to achieve standardized adaptation of diverse vehicle information, solving the problem of poor standardization in the diagnostic process. By reverse-engineering the vehicle fault codes, a precise PID list and collection strategy are determined, enabling on-demand triggering and data collection, avoiding invalid data scanning, and improving the efficiency of diagnostic report generation.

[0029] Please see Figure 1 , Figure 1 This is a schematic diagram of the structure of a vehicle diagnostic system provided in an embodiment of this application, as shown below. Figure 1 As shown, the vehicle diagnostic system 100 includes a master control module 101 and a slave control module 102.

[0030] The main control module 101 is equipped with an intelligent agent (such as OpenClaw), which acts as the system brain. It receives high-level diagnostic objectives (such as "generate a complete diagnostic report") input by the technician, and automatically plans a complete diagnostic operation sequence based on the built-in diagnostic knowledge graph and vehicle context (model, year, known fault codes). It also dynamically selects, loads, and calls the corresponding plugins to complete the data reading and parsing tasks.

[0031] The slave control module 102 is equipped with diagnostic software, which is used to perform diagnostic operations on the vehicle. The master control module 101 and the slave control module 102 can be installed on the same terminal device.

[0032] In this application, the intelligent agent in the main control module 101 calls the diagnostic software in the slave control module 102 to obtain diagnostic report requirements, vehicle information, and vehicle fault codes. The diagnostic report requirements indicate the diagnostic report that needs to be issued. Based on the vehicle information, the functional plug-in corresponding to the vehicle information is determined from the plug-in library, which includes functional plug-ins for different vehicle models. The OBD protocol, PID list, and acquisition strategy are determined from the functional plug-in based on the vehicle fault codes. The vehicle's OBD interface is accessed based on the OBD protocol, and the vehicle's first data is obtained based on the PID list and acquisition strategy. The first data is mapped into readable fields based on the functional plug-in to obtain the second data. The diagnostic report is generated based on the functional plug-in, the diagnostic report requirements, and the second data.

[0033] By replacing traditional manual operations with intelligent agents and utilizing pre-built functional plugins for different vehicle models in the plugin library, standardized adaptation to diverse vehicle information is achieved, solving the problem of poor standardization in the diagnostic process. By reverse-engineering vehicle fault codes to determine a precise PID list and collection strategy, on-demand triggering and data collection are realized, avoiding invalid data scanning and improving diagnostic efficiency. Based on functional plugins, the underlying first data is mapped into readable fields to obtain the second data, eliminating errors from manual interpretation of the data stream and ensuring data reliability. Thus, highly efficient, highly reliable vehicle diagnosis without human intervention can be achieved.

[0034] Based on this, the present application provides a method for generating a vehicle diagnostic report. The embodiments of the present application will be described in detail below with reference to the accompanying drawings.

[0035] Example 1: The main process of generating vehicle diagnostic reports will be described below.

[0036] Please see Figure 2 , Figure 2 This is a flowchart illustrating a vehicle diagnostic report generation method provided in an embodiment of this application. This method is applied to the aforementioned main control module, such as... Figure 2 As shown, the method includes the following steps.

[0037] Step S201: Call the diagnostic software to obtain diagnostic report requirements, vehicle information, and vehicle fault codes.

[0038] The intelligent agent can be an AI agent core based on the OpenClaw architecture, possessing automated control and decision-making capabilities. In this embodiment, the intelligent agent obtains root privileges on the Android system to achieve non-intrusive automated control of the original diagnostic software. As the executor, the intelligent agent coordinates each stage of the diagnostic process, achieving a closed loop from target specification to report generation. For example, the intelligent agent can be one or more of rule-driven, model-driven, or hybrid-driven agents.

[0039] Diagnostic report requests can be the type and target of a diagnostic report specified by the user or technician. These requests serve as input instructions, guiding the agent to determine the diagnostic scope and report format. Vehicle information can be a set of data describing the vehicle's identity and configuration. It serves as a matching basis for selecting suitable functional plugins from the plugin library. Vehicle fault codes can be standardized error codes detected by the onboard system, indicating specific system anomalies. These codes act as trigger conditions, used to reverse-engineer precise data acquisition parameters. In one specific embodiment, vehicle fault codes can be powertrain fault codes, chassis system fault codes, body electrical fault codes, etc.

[0040] Calling diagnostic software to obtain diagnostic reports, vehicle information, and vehicle fault codes can be done by receiving user commands through an input interface and then using the diagnostic software to scan the vehicle system to obtain basic information and fault codes.

[0041] Step S202: Based on the vehicle information, determine the functional plugin corresponding to the vehicle information from the plugin library.

[0042] The plugin library can be a database or file collection storing functional plugins corresponding to different vehicle models. Functional plugins can be pre-built modular logic code units for specific vehicle models or systems. Functional plugins define the necessary implementation strategies required to fulfill diagnostic report requirements. Determining the corresponding functional plugin from the plugin library based on vehicle information can be achieved by comparing vehicle information features with the plugin library index and filtering out matching functional plugins.

[0043] Step S203: Determine the OBD protocol, PID list, and acquisition strategy from the function plug-in using the vehicle fault codes.

[0044] The OBD protocol can be a standard rule for communication between external diagnostic equipment and internal electronic control units (ECUs). As the communication foundation, the OBD protocol ensures that diagnostic equipment can correctly connect to the vehicle interface and exchange data. In an exemplary embodiment, the OBD protocol can be ISO15765-4, SAE J1850, ISO14230-4, etc. The PID list can be a set of identifiers specifying the specific data items to be collected. The PID list clarifies the data collection scope, avoids invalid data scanning, and improves diagnostic efficiency. Furthermore, the PID list can be engine status PID, sensor voltage PID, system readiness PID, etc.

[0045] A data acquisition strategy can be a logical rule that specifies the frequency, timing, and conditions for data acquisition. The acquisition strategy optimizes the data acquisition process, enabling on-demand triggering and ensuring data timeliness and reliability. By using vehicle fault codes to determine the OBD protocol, PID list, and acquisition strategy from the functional plugin, one can analyze the meaning of the fault codes, consult the mapping table within the functional plugin, and extract the corresponding protocol type, PID, and strategy. This enables on-demand triggering and data acquisition, avoids invalid data scanning, and improves diagnostic efficiency.

[0046] Step S204: Access the vehicle's OBD interface based on the OBD protocol, and obtain the vehicle's first data based on the PID list and acquisition strategy.

[0047] The vehicle's OBD interface can be a standardized physical connector on the vehicle used to connect external diagnostic equipment. The vehicle's OBD interface provides a physical connection channel, enabling diagnostic equipment to access the vehicle's internal network. The first data can be the raw, low-level data stream directly obtained through the OBD interface. This first data, as raw input, contains unprocessed hexadecimal or binary information. Accessing the vehicle's OBD interface based on the OBD protocol can be achieved by establishing physical and logical connections with the vehicle's OBD interface using a defined OBD protocol standard.

[0048] Furthermore, the OBD interface of a vehicle, based on the OBD protocol, can be connected wirelessly via a Bluetooth adapter, wired via a USB-to-OBD cable, or via a WiFi module. This establishes a communication link, provides a channel for data acquisition, and ensures technical effectiveness in terms of communication compatibility. Acquiring the vehicle's initial data based on a PID list and acquisition strategy involves sending requests to the vehicle according to a specified PID list and strategy, and receiving the returned raw data stream. This allows for the acquisition of underlying raw information, providing material for data parsing and ensuring data integrity.

[0049] Step S205: Based on the functional plugin, the first data is mapped to a readable field to obtain the second data.

[0050] In this context, readable fields can map raw data to labels or units with clear semantics. Readable fields eliminate human interpretation errors, giving the underlying data a meaning that is understandable to humans. In an exemplary embodiment, readable fields can be text label fields, numerical unit fields, status description fields, etc. For example, the raw PID "0104" can be mapped to the readable field "engine load".

[0051] The second data can be structured data with semantic information after mapping processing. Furthermore, based on functional plugins, the first data is mapped into readable fields, and the second data can be converted into numerical values ​​through formula calculations, state conversions through table lookups, and description conversions through logical judgments. This eliminates the errors of manual interpretation of the data stream and ensures the reliability and understandability of the data.

[0052] Step S206: Generate a diagnostic report based on the functional plugin, diagnostic report requirements, and second data.

[0053] The diagnostic report can be a professional document containing diagnostic results and recommendations as the final output. The diagnostic report presents the final result of an end-to-end intelligent closed loop for technicians or users to review. In one specific embodiment, the diagnostic report can be a text-formatted report, a chart-formatted report, a mixed-format report, etc. Generating a diagnostic report based on functional plugins, diagnostic report requirements, and second data can involve integrating the second data and requirements, and using templates or generation logic within the plugin to output the final report. Furthermore, generating a diagnostic report based on functional plugins, diagnostic report requirements, and second data can be achieved through methods such as filling content with fixed templates, generating text based on AI models, and assembling paragraphs based on rule engines. This achieves an end-to-end closed loop from specifying high-level diagnostic goals to automatically generating a professional report, without requiring manual intervention.

[0054] In this embodiment, an intelligent agent replaces the traditional manual operation of technicians. By utilizing pre-built functional plugins for different vehicle models in the plugin library, standardized adaptation of diverse vehicle information is achieved, solving the problem of poor standardization in the diagnostic process. By reverse-engineering the vehicle fault codes to determine the accurate PID list and collection strategy, on-demand triggering and data collection are realized, avoiding invalid data scanning and improving diagnostic efficiency. Based on the functional plugins, the underlying first data is mapped into readable fields to obtain the second data, eliminating the error of manual interpretation of the data stream and ensuring data reliability. Thus, high-efficiency, high-reliability vehicle diagnosis without human intervention can be achieved.

[0055] In Example 2, the functional plug-in may include an OBD communication adapter, a data acquisition strategy lookup table, a data flow semantic mapping table, anomaly judgment rules, and a report template. The OBD communication adapter is used to define the OBD protocol supported by the vehicle model corresponding to the functional plug-in. The data acquisition strategy lookup table is used to define the list of PIDs to be read and the data acquisition strategy when different fault codes exist. The data flow semantic mapping table is used to map the original PIDs into readable fields. The anomaly judgment rules are used to judge abnormal data in the second data.

[0056] The following section provides a detailed explanation of the vehicle diagnostic report generation method, based on the refinement of the functional plugins.

[0057] Please see Figure 3 , Figure 3 This is a flowchart illustrating another vehicle diagnostic report generation method provided in an embodiment of this application. This method is applied to the aforementioned main control module, such as... Figure 3 As shown, the method includes the following steps.

[0058] Step S301: Call the diagnostic software to obtain diagnostic report requirements, vehicle information, and vehicle fault codes.

[0059] Step S302: Determine the functional plugin corresponding to the vehicle information from the plugin library based on the vehicle information.

[0060] Step S303: Determine the OBD protocol based on the OBD communication adapter.

[0061] The OBD communication adapter can be a sub-module within a functional plugin used to define the vehicle model's support for the OBD protocol. The OBD communication adapter can be built into the functional plugin and invoked by the agent to identify the communication standard. The OBD communication adapter can shield the complexity of the underlying communication protocol and resolve the issue of standardization discrepancies. Determining the OBD protocol based on the OBD communication adapter can be achieved by the agent invoking the OBD communication adapter within the functional plugin and reading its configured protocol type information.

[0062] Step S304: Determine the matching PID list and acquisition strategy from the acquisition strategy lookup table based on the vehicle fault codes.

[0063] The data acquisition strategy lookup table can be a submodule within a functional plugin that defines the mapping relationship between fault codes, PID lists, and data acquisition strategies. The lookup table can be stored as a lookup table, supporting quick matching of acquisition parameters based on fault code indices. It can be used to establish a direct mapping between fault codes and acquisition parameters, enabling on-demand data acquisition. In an exemplary embodiment, the lookup table can be categorized based on different mapping dimensions, including single fault code mapping tables, multi-fault code combination mapping tables, and system-level mapping tables.

[0064] Taking the accurate diagnosis of faults in a specific vehicle model as an example, the vehicle diagnostic report generation method in this embodiment can be that the agent loads a function plug-in for a certain German vehicle model. The OBD communication adapter in the plug-in is specified to use the ISO15765-4 protocol. When an engine misfire fault code is read, the agent queries the acquisition strategy lookup table in the plug-in and directly locks the speed, load and oxygen sensor PID list associated with the fault code, as well as the corresponding high-frequency acquisition strategy.

[0065] In this embodiment, by refining the functional plug-in into an OBD communication adapter and a data acquisition strategy lookup table, the diagnostic logic is structured and modularized. The OBD communication adapter encapsulates the differences in OBD protocols supported by different vehicle models, shielding the complexity of the underlying communication protocol and solving the problem of standardization difference. The data acquisition strategy lookup table establishes a direct mapping relationship between fault codes, PID lists, and acquisition strategies, enabling the system to trigger data acquisition as needed based on specific fault codes, avoiding the time wasted by full scans and significantly improving diagnostic efficiency. This automated determination mechanism based on lookup tables replaces the process of technicians manually selecting parameters, eliminating human configuration errors and ensuring the accuracy and reliability of data acquisition.

[0066] Step S305: Access the vehicle's OBD interface based on the OBD protocol, and obtain the vehicle's first data based on the PID list and acquisition strategy.

[0067] Step S306: Based on the data flow semantic mapping table in the functional plugin, the first data is mapped to a readable field to obtain the second data.

[0068] The data flow semantic mapping table can be a database structure within a functional plugin that stores the correspondence between raw PID data and readable fields. In this embodiment, the data flow semantic mapping table can automatically convert underlying data to upper-level semantics, eliminating errors from manual interpretation. Furthermore, the data flow semantic mapping table can be one or more of the following: a one-to-one mapping table, a one-to-many mapping table, and a conditional logic mapping table. The raw PID can be a unique code that identifies a specific data item in the vehicle data flow.

[0069] Based on the data flow semantic mapping table in the functional plugin, the first data is mapped into a readable field to obtain the second data. This can be done by reading the PID identifier in the first data, looking up the corresponding rule in the mapping table, and converting the original PID into semantics with physical meaning.

[0070] In this embodiment, a standardized semantic association between the underlying raw PID data and the upper-level readable fields is established by introducing a data flow semantic mapping table. This mapping table, as part of a functional plugin, enables the system to automatically convert the raw data returned by the vehicle into diagnostic information with clear physical meaning, eliminating errors from manual data translation. Combined with the automated control of an AI agent, this semantic mapping mechanism ensures the accuracy and professionalism of the generated diagnostic report.

[0071] Step S307: Determine the target report template from the report templates based on the diagnostic report requirements.

[0072] The report template can be a diagnostic report structure and content framework defined within a functional plugin. It can be used to standardize the generation of diagnostic report formats and content, avoiding the inefficiency and poor standardization issues caused by manual writing. In this embodiment, the report template is stored as a structured file, containing fixed text, variable placeholders, and formatting styles. For example, depending on the presentation format, the report template can be one or more of the following: text description template, chart display template, and mixed layout template.

[0073] Furthermore, the target report template can be determined from the report templates based on the diagnostic report requirements through precise keyword matching, semantic similarity calculation, and recommendation matching based on historical selection. This enables the standardized generation of diagnostic report formats and content, adapting to different levels of diagnostic objectives.

[0074] Step S308: Generate a diagnostic report based on the anomaly judgment rules, the second data, and the target report template.

[0075] Among them, the anomaly judgment rules can be a set of logical conditions pre-set in the functional plugin for identifying abnormal states in the data stream. This can be used to transform the process of technicians relying on experience to identify data anomalies into automated logical judgments, eliminating subjective differences in manual analysis.

[0076] In this embodiment, the anomaly detection rules are stored in the functional plugin, and the second data is verified in real time through threshold comparison, trend analysis, or logical association algorithms. For example, the anomaly detection rules may include, but are not limited to, one or more of the following, depending on the judgment criteria: threshold exceeding rules, trend abrupt change rules, and logical association rules. Abnormal data can be a subset of the second data that has been marked as exceeding the normal range after verification by the anomaly detection rules. This data can be used as the core issue basis in the diagnostic report, highlighting the vehicle's fault points.

[0077] Identifying anomalous data in the second set of data can be achieved by an intelligent agent invoking anomaly detection rules, iterating through each field in the second set of data, and comparing it against preset conditions. This eliminates subjective differences and oversights inherent in manual data stream analysis, resolving error-prone issues. Furthermore, generating a diagnostic report based on the anomaly detection rules, the second set of data, and the target report template allows for the input of anomalous data into designated locations within the target report template. Combining this with the rule conclusions generates a complete text, ensuring the professionalism and consistency of the output. Coupled with automated data collection and parsing at the front end, this truly achieves an end-to-end intelligent closed loop from high-level target specification to final report output.

[0078] In this embodiment, by introducing anomaly judgment rules, the process of technicians relying on experience to identify data anomalies is transformed into automated logical judgment, eliminating subjective differences and omissions when manually analyzing data streams and solving the problem of easy errors. By using the matching mechanism between report templates and diagnostic report requirements, the standardized generation of diagnostic report format and content is realized, avoiding the problems of low efficiency and poor standardization caused by manual report writing. The automatic combination of rules, data and templates to generate diagnostic reports ensures the professionalism and consistency of the output results.

[0079] Example 3: The method for generating a vehicle diagnostic report will be described in detail below based on the details of obtaining the first data.

[0080] Please see Figure 4 , Figure 4 This is a flowchart illustrating another vehicle diagnostic report generation method provided in this application embodiment. This method is applied to the aforementioned main control module, such as... Figure 4 As shown, the method includes the following steps.

[0081] Step S401: Call the diagnostic software to obtain diagnostic report requirements, vehicle information, and vehicle fault codes.

[0082] Step S402: Based on the vehicle information, determine the functional plugin corresponding to the vehicle information from the plugin library.

[0083] Step S403: Determine the On-Board Diagnostic System (OBD) protocol, parameter identifier PID list, and acquisition strategy from the functional plug-in using the vehicle fault codes.

[0084] Step S404: Obtain the standard interactive process corresponding to vehicle information, PID list and collection strategy from the interactive knowledge base.

[0085] The interactive knowledge base can be a digital knowledge set storing standard interactive procedures for different vehicle information and PID lists. The interactive knowledge base can be used to transform technicians' experience-based memorization of operational steps into reusable digital knowledge. In this embodiment, the interactive knowledge base can be stored through a database or file system. The interactive knowledge base supports index queries based on vehicle features and diagnostic parameters. For example, the interactive knowledge base can include, but is not limited to, one or more of relational knowledge bases, graph knowledge bases, and vector knowledge bases.

[0086] A standard interaction flow can be a standardized sequence of operational steps required for data acquisition in diagnostic software. Standard interaction flows can replace tedious manual operations such as clicking menus and selecting parameters by technicians. Furthermore, standard interaction flows can be retrieved from an interaction knowledge base. Standard interaction flows include action instructions such as menu clicking, parameter selection, and data reading. In an exemplary embodiment, a standard interaction flow may include, but is not limited to, linear execution flows, branch-based decision flows, and loop-based retry flows.

[0087] The standard interactive process corresponding to vehicle information, PID list, and acquisition strategy can be obtained from the interactive knowledge base, using vehicle information, PID list, and acquisition strategy as a combined index key.

[0088] In some embodiments, the interactive knowledge base can be obtained by: acquiring a task set and required vehicle models, wherein the task set includes multiple tasks, and each task includes a list of PIDs to be collected and a corresponding collection strategy; performing task simulation on the diagnostic software based on the task set and required vehicle models and obtaining interface interaction information with the diagnostic software; processing the interface interaction information to generate a standard interaction process corresponding to each task in the task set and each vehicle model in the required vehicle models; and constructing an interactive knowledge base based on the vehicle model-task structure.

[0089] The task set can be a collection of multiple diagnostic tasks. The task set can be pre-configured or obtained synchronously from the cloud, serving as the input source for automated simulation. The required vehicle model can be the target vehicle model information specified during the knowledge base construction process, used to ensure that the generated interactive flow matches the diagnostic software interface of a specific vehicle model. Furthermore, the required vehicle model serves as a dimension index to determine the specific operating environment and interface characteristics of the diagnostic software. In an exemplary embodiment, the required vehicle model is categorized by identification granularity, such as specific VIN code vehicle model, vehicle series / model model, or brand-general vehicle model.

[0090] Each task in the task set can contain a list of PIDs to be collected and their corresponding acquisition strategies, serving as the basic unit of simulation execution to drive the diagnostic software to complete specific data acquisition actions. Obtaining the task set and the required vehicle model can be done by reading a preset task list and target vehicle model identifier from a configuration file or database.

[0091] Interface interaction information can be the operation trajectory and response data of the diagnostic software interface captured during task simulation, which can be used to convert manual operation trajectories into standard interactive processes that can be executed by machines. In this embodiment, interface interaction information is obtained by listening to system input events or recording interface changes through accessibility services. For example, interface interaction information, categorized by data format, can include, but is not limited to, one or more of the following: touch event sequences, interface element trees, screen jump records, etc.

[0092] Simulating tasks for diagnostic software based on task sets and required vehicle models, and acquiring interface interaction information with the diagnostic software, can involve controlling the diagnostic software to execute operations within the task set, while simultaneously recording interface responses and interaction events in the background. Furthermore, simulating tasks for diagnostic software based on task sets and required vehicle models, and acquiring interface interaction information with the diagnostic software, can be achieved through script-driven automatic clicks, AI-assisted visual recognition of operations, or by injecting commands into the system's underlying layer.

[0093] Process the interface interaction information to generate standard interaction processes for each task in the task set and each vehicle model in the required vehicle model. This can be done by cleaning the original interaction logs, removing redundant steps, standardizing element identifiers, and forming reusable process files.

[0094] Building an interactive knowledge base based on a vehicle model-task structure involves storing the generated standard interactive processes in a database or file system according to vehicle model and task dimensions. Furthermore, this vehicle model-task structure can be implemented using relational databases, graph databases to store relationships, or file system indexes. This provides a reusable operational knowledge foundation for AI agents, supporting large-scale storage and management of diagnostic operation logic for different vehicle models.

[0095] In this embodiment, by transforming the captured original operation trajectory into a standard interactive process that can be executed by the machine, the uncertainty of human operation is eliminated, providing a reusable operational knowledge base for the AI ​​agent, realizing the automated recording and learning of diagnostic operation processes, and solving the problems of low efficiency and poor standardization caused by reliance on manual operation by technicians in the background technology.

[0096] Step S405: Access the vehicle's OBD interface based on the OBD protocol, and execute the standard interactive process in the diagnostic software to obtain the vehicle's first data.

[0097] The diagnostic software can be an original equipment manufacturer (OEM) vehicle diagnostic application running on an operating system (such as Android). The diagnostic software executes standard interactive processes to acquire initial vehicle data; this can be achieved through an intelligent agent simulating user actions or injecting commands.

[0098] In this embodiment, interactive actions are automatically executed in the diagnostic software based on standard interactive processes, replacing the tedious operations of technicians manually clicking menus and selecting parameters, which significantly improves the efficiency of generating diagnostic reports.

[0099] In one embodiment, the standard interaction process includes multiple consecutive sub-interaction goals and semantic descriptions and verification conditions corresponding to each sub-goal. The standard interaction process is executed in the diagnostic software to obtain the vehicle's first data, including: Obtain the interface adaptation description file corresponding to the diagnostic software. The interface adaptation description file is used to define the implementation methods of page semantic acquisition operations and control matching click operations. S1. Based on the current sub-interaction goal in the standard interaction process, obtain the current page state of the operation perception diagnostic software through page semantics, and determine whether the current sub-interaction goal has been achieved based on the verification conditions of the current sub-interaction goal. S2, if not achieved, then in the set of interactive elements corresponding to the current page state, match the target control that is most relevant to the semantic description of the current sub-interaction target, and execute the interaction between the target control and the click operation through the control matching; S3, if achieved, the next sub-interaction target among multiple consecutive sub-interaction targets will be taken as the current sub-interaction target, and in the set of interactive elements corresponding to the current page state, the target control most relevant to the semantic description of the current sub-interaction target will be matched, and the interaction between the target control and the click operation will be executed through the control matching. Repeat steps S1 to S3 until the last sub-interaction goal in the standard interaction process is achieved and the first data is obtained.

[0100] The interface adaptation description file can be a configuration file that defines the semantic acquisition and control matching click implementation methods of the diagnostic software page, and can be used to achieve decoupling and abstraction at the UI level of the diagnostic software. In this embodiment, the interface adaptation description file can be stored locally or in the cloud, and includes interface element feature extraction rules and interaction action mapping logic. Obtaining the interface adaptation description file corresponding to the diagnostic software can be achieved by the intelligent agent reading the corresponding adaptation configuration file from the storage medium based on the diagnostic software version information. Furthermore, obtaining the interface adaptation description file corresponding to the diagnostic software can be achieved through various methods such as loading from a local preset directory, dynamically downloading from a cloud server, or reading historical files from a cache area, thereby achieving decoupling and abstraction at the UI level of the diagnostic software.

[0101] Page semantic acquisition can be a technical action in the perception and diagnostic software to determine the current page state, providing real-time environmental information for subsequent control matching. In this embodiment, page semantic acquisition can involve calling system interfaces or image algorithms to extract interface element information and layout structure, obtaining a set of semantic attributes for all interactive controls. The output of this operation can be a structured list of interactive controls, where each item contains the textual semantic information of that control, used for subsequent matching and determination with logical sub-targets. The current page state can be the element layout and content presentation of the diagnostic software interface at a certain moment, serving as a basis for determining whether sub-interaction targets have been achieved and reflecting the real-time running status of the software. The perception and diagnostic software's current page state can be obtained through page semantic acquisition by traversing the system's accessibility node tree, performing OCR recognition on screenshots, and listening to window focus change events.

[0102] Because different diagnostic software may have different interaction flows for the same task, but the OBD-II standard diagnostic flow defines the basic functional categories of diagnostics: powertrain, chassis, body, network communication, etc., any diagnostic software, regardless of its interface design, must adhere to this functional classification system. Therefore, by "reverse-inductively" summarizing the common functional logic of multiple mainstream diagnostic software, an interaction flow adaptable to different diagnostic software can be abstracted. This standard interaction flow can then be set as multiple sub-interaction goals, each representing the necessary process to complete the corresponding task.

[0103] For example, the logical derivation process for obtaining multiple sub-interaction goals may include: No diagnostic software, in order to "read real-time data streams from specific sensors," can solve a fixed logical chain: You need to tell the software which vehicle you want to diagnose. The corresponding functional logic at this point is: vehicle identification verification. You need to access the vehicle's powertrain / engine control system. The corresponding function logic at this point is: System Selection; You need to find the "View Real-Time Data" function module. The corresponding functional logic at this point is: function selection; You need to specify which sensor you want to monitor from among hundreds or thousands of PIDs. This corresponds to the functional logic: object selection. You need to confirm before the data refresh begins. The corresponding functional logic at this point is: execute confirmation.

[0104] At this point, multiple sub-interaction goals are determined based on various functional logics. This allows the standard interaction process to be adapted to multiple different diagnostic software programs.

[0105] Verification conditions can be a set of logical rules used to determine whether the current sub-interaction goal has been achieved. They can be used to ensure the accuracy and robustness of the interaction steps and avoid invalid operations. In this embodiment, verification conditions can be bound to sub-interaction goals, and the current page state can be verified after each interaction. For example, verification conditions can be one or more of the following, depending on the verification dimension: element existence verification, text content verification, and state color value verification. Determining whether the current sub-interaction goal has been achieved based on its verification conditions can involve comparing the current page state features with the verification condition rules and outputting a boolean result.

[0106] Semantic descriptions can be textual or feature-based expressions of the meaning of a sub-interaction target or control function. In this embodiment, the semantic description can be pre-defined in the sub-interaction target or interface adaptation description file and used for comparison with the actual interface elements.

[0107] For example, the sub-interaction target: G2_Enter Engine System; semantic description: Enter the engine / powertrain control unit function page of the target vehicle; verification conditions: "The control tree of the current page contains at least one control with the text containing 'engine' or 'powertrain'", "The current page contains a control with the text containing 'data stream' or 'read data' or 'LiveData'".

[0108] The set of interactive elements can be a summary of all operable controls in the current page state, which can be used to provide a candidate range of target controls and narrow down the matching search space. The target control can be a specific interface element in the set of interactive elements that is most relevant to the semantic description of the sub-interaction target, and can be used as the specific object to perform the interactive action, directly driving the software function response. In this embodiment, matching the target control most relevant to the semantic description of the current sub-interaction target can be achieved by calculating the similarity between each element in the set of interactive elements and the semantic description, and selecting the element with the highest score.

[0109] A control matching click operation can be a technical action performed to interact with a target control within a set of interactive elements. In this embodiment, the control matching click operation can simulate user input events or inject system commands based on the matching result. Furthermore, the control matching click operation can be one or more of the following, depending on the execution method: coordinate-simulated click, event-injected click, or accessibility function click. Taking the next sub-interaction target among multiple consecutive sub-interaction targets as the current sub-interaction target can be achieved by updating the flow pointer and setting the next item in the sequence as the task to be executed.

[0110] In this embodiment, the implementation method of page semantic acquisition and control matching click is defined by the interface adaptation description file, which realizes the decoupling and abstraction of the interface layer of the diagnostic software. The current page state of the diagnostic software is perceived through the page semantic acquisition operation. It is determined whether the current sub-interaction target has been achieved according to the verification conditions of the current sub-interaction target, which ensures the accuracy and robustness of the interaction steps. By matching the target control most relevant to the semantic description of the current sub-interaction target, the interaction between the target control and the control matching click operation is executed, which replaces the process of technicians manually searching for menus and buttons and realizes a high degree of standardization of the diagnostic process. By taking the next sub-interaction target of the current sub-interaction target in multiple consecutive sub-interaction targets as the current sub-interaction target, the standard interaction process is driven forward until the last sub-interaction target is achieved and the first data is obtained. This closed-loop perception, judgment and execution mechanism ensures fully automatic unmanned operation from high-level diagnostic targets to data acquisition, thereby achieving the technical effect of highly reliable automated control and end-to-end intelligent closed loop.

[0111] Step S406: Based on the functional plugin, the first data is mapped to a readable field to obtain the second data.

[0112] Step S407: Generate a diagnostic report based on the functional plugin, diagnostic report requirements, and second data.

[0113] For embodiments consistent with those shown above, please refer to... Figure 5 , Figure 5 This application provides a functional unit block diagram of a vehicle diagnostic report generation device, which is a part of the main control module described above. Figure 5 As shown, the vehicle diagnostic report generation device 50 includes: The first processing unit 501 is used to call the diagnostic software to obtain diagnostic report requirements, vehicle information and vehicle fault codes. The diagnostic report requirements are used to indicate the diagnostic report that needs to be issued. The second processing unit 502 is used to determine the functional plug-in corresponding to the vehicle information from the plug-in library based on the vehicle information. The plug-in library includes functional plug-ins corresponding to different vehicle models. The third processing unit 503 is used to determine the on-board diagnostic system OBD protocol, parameter identifier PID list, and acquisition strategy from the functional plug-in through vehicle fault codes. The third processing unit 503 is also used to access the vehicle's OBD interface based on the OBD protocol and to obtain the vehicle's first data based on the PID list and acquisition strategy. The third processing unit 503 is also used to map the first data into a readable field based on the functional plug-in to obtain the second data; The third processing unit 503 is also used to generate a diagnostic report based on the functional plug-in, diagnostic report requirements, and second data.

[0114] In one feasible embodiment, the functional plug-in includes an OBD communication adapter and a data acquisition strategy lookup table. The OBD communication adapter is used to define the OBD protocol supported by the vehicle model corresponding to the functional plug-in, and the data acquisition strategy lookup table is used to define the PID list and acquisition strategy to be read when different fault codes exist. Specifically, the third processing unit 503 is used to determine the corresponding on-board diagnostic system OBD protocol, PID list, and acquisition strategy from the functional plug-in based on the vehicle fault codes: Determine the OBD protocol based on the OBD communication adapter; Based on the vehicle fault codes, the matching PID list and acquisition strategy are determined from the acquisition strategy lookup table.

[0115] In one feasible embodiment, the functional plug-in includes a data flow semantic mapping table, which is used to map the original PID to a readable field. In terms of mapping the first data to a readable field based on the functional plug-in to obtain the second data, the third processing unit 503 is specifically used for: The first data is mapped to readable fields based on the data flow semantic mapping table in the functional plugin to obtain the second data.

[0116] In one feasible embodiment, the functional plugin includes anomaly judgment rules and a report template. The anomaly judgment rules are used to judge abnormal data in the second data. Regarding the generation of a diagnostic report based on the functional plugin, diagnostic report requirements, and the second data, the third processing unit 503 is specifically used for: The target report template is determined from the report templates based on the diagnostic report requirements; A diagnostic report is generated based on anomaly detection rules, secondary data, and the target report template.

[0117] In a feasible embodiment, regarding the access to the vehicle's OBD interface based on the OBD protocol and the acquisition of the vehicle's first data based on the PID list and acquisition strategy, the third processing unit 503 is specifically used for: The standard interaction process corresponding to vehicle information, PID list and acquisition strategy is obtained from the interaction knowledge base, which is used to define the interaction process of the diagnostic software. Access the vehicle's OBD interface based on the OBD protocol, and execute a standard interactive process in the diagnostic software to obtain the vehicle's initial data.

[0118] In one feasible embodiment, the third processing unit 503 is further configured to: Obtain the task set and the required vehicle models. The task set includes multiple tasks, and each task includes a list of PIDs to be collected and the corresponding collection strategy. Based on the task set and the required vehicle model, the diagnostic software is used to perform task simulation and obtain the interface interaction information with the diagnostic software. Process the interface interaction information to generate standard interaction processes for each task in the task set and each vehicle model in the required vehicle models; An interactive knowledge base is built based on a vehicle model-task structure.

[0119] In one feasible embodiment, the standard interaction process includes multiple consecutive sub-interaction objectives and semantic descriptions and verification conditions corresponding to each sub-objective. Regarding the aspect of executing the standard interaction process in the diagnostic software to obtain the vehicle's first data, the third processing unit 503 is specifically used for: Obtain the interface adaptation description file corresponding to the diagnostic software. The interface adaptation description file is used to define the implementation methods of page semantic acquisition operations and control matching click operations. S1. Based on the current sub-interaction goal in the standard interaction process, obtain the current page state of the operation perception diagnostic software through page semantics, and determine whether the current sub-interaction goal has been achieved based on the verification conditions of the current sub-interaction goal. S2, if not achieved, then in the set of interactive elements corresponding to the current page state, match the target control that is most relevant to the semantic description of the current sub-interaction target, and execute the interaction between the target control and the click operation through the control matching; S3, if achieved, the next sub-interaction target among multiple consecutive sub-interaction targets will be taken as the current sub-interaction target, and in the set of interactive elements corresponding to the current page state, the target control most relevant to the semantic description of the current sub-interaction target will be matched, and the interaction between the target control and the click operation will be executed through the control matching. Repeat steps S1 to S3 until the last sub-interaction goal in the standard interaction process is achieved and the first data is obtained.

[0120] It is understood that since the method embodiments and the device embodiments are different presentations of the same technical concept, the content of the method embodiment section in this application should be adapted to the device embodiment section, and will not be repeated here.

[0121] When using integrated units, such as Figure 6 As shown, Figure 6 This is a block diagram of the functional units of another vehicle diagnostic report generation device provided in an embodiment of this application. Figure 6The vehicle diagnostic report generation device 50 includes a processing module 612 and a communication module 611. The processing module 612 controls and manages the operation of the vehicle diagnostic report generation device 50, such as the steps of the first processing unit 501, the second processing unit 502, and the third processing unit 503, and / or other processes for executing the techniques described herein. The communication module 611 supports interaction between the vehicle diagnostic report generation device 50 and other devices. Figure 6 As shown, the vehicle diagnostic report generation device 50 may also include a storage module 613, which is used to store the program code and data of the vehicle diagnostic report generation device 50.

[0122] The processing module 612 can be a processor or controller, such as a central processing unit (CPU), a general-purpose processor, a digital signal processor (DSP), an ASIC, an FPGA, or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof. It can implement or execute the various exemplary logic blocks, modules, and circuits described in conjunction with the disclosure of this application. The processor can also be a combination that implements computational functions, such as a combination of one or more microprocessors, a combination of a DSP and a microprocessor, etc. The communication module 611 can be a transceiver, RF circuitry, or a communication interface, etc. The storage module 613 can be a memory.

[0123] All relevant content in each scenario involved in the above method embodiments can be referenced from the functional descriptions of the corresponding functional modules, and will not be repeated here. The vehicle diagnostic report generation device 50 described above can all perform the above... Figure 2 The method for generating vehicle diagnostic reports is shown.

[0124] The above embodiments can be implemented, in whole or in part, by software, hardware, firmware, or any other combination thereof. When implemented using software, the above embodiments can be implemented, in whole or in part, as a computer program product. A computer program product includes one or more computer instructions or computer programs. When the computer instructions or computer programs are loaded or executed on a computer, all or part of the processes or functions according to the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. Computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired or wireless means. A computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that includes one or more sets of available media. Available media can be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., DVDs), or semiconductor media. Semiconductor media can be solid-state drives.

[0125] Figure 7 This is a structural block diagram of an electronic device provided in an embodiment of this application. Figure 7 As shown, the electronic device 700 may include one or more of the following components: processor 701, memory 702 and communication interface 703. The processor 701, memory 702 and communication interface 703 are interconnected and perform communication between them. The memory 702 may store one or more computer programs. The one or more computer programs may be configured to implement the methods described in the above embodiments when executed by one or more processors 701.

[0126] Processor 701 may include one or more processing cores. Processor 701 connects to various parts within the electronic device 700 using various interfaces and lines, and performs various functions and processes data of the electronic device 700 by running or executing instructions, programs, code sets, or instruction sets stored in memory 702, and by calling data stored in memory 702. Optionally, processor 701 may be implemented using at least one hardware form of Digital Signal Processing (DSP), Field-Programmable Gate Array (FPGA), or Programmable Logic Array (PLA). Processor 701 may integrate one or more of a Central Processing Unit (CPU), Graphics Processing Unit (GPU), and modem. It is understood that the aforementioned modem may also not be integrated into processor 701, but may be implemented separately through a communication chip.

[0127] The memory 702 may include random access memory (RAM) or read-only memory (ROM). The memory 702 can be used to store instructions, programs, code, code sets, or instruction sets. The memory 702 may include a program storage area and a data storage area. The program storage area may store instructions for implementing an operating system, instructions for implementing at least one function (such as touch functionality, sound playback functionality, image playback functionality, etc.), and instructions for implementing the various method embodiments described above. The data storage area may also store data created by the electronic device 700 during use.

[0128] It is understood that the electronic device 700 may include more or fewer structural elements than those shown in the above block diagram, such as a power module, physical buttons, WiFi (Wireless Fidelity) module, speaker, Bluetooth module, sensor, etc., without limitation.

[0129] The aforementioned electronic device 700 may be a main control module or a part of a main control module.

[0130] This application provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements some or all of the steps of any of the vehicle diagnostic report generation methods described in the above method embodiments.

[0131] This application also provides a computer program product, including a computer program that, when executed by a processor, implements some or all of the steps of any of the vehicle diagnostic report generation methods described in the above method embodiments. This computer program product can be a software installation package.

[0132] It should be noted that, for the sake of simplicity, all of the aforementioned vehicle diagnostic report generation method embodiments are described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions involved are not necessarily essential to this application.

[0133] Although this application has been described herein in conjunction with various embodiments, those skilled in the art, by reviewing the accompanying drawings, disclosure, and appended claims, will understand and implement other variations of the disclosed embodiments in carrying out the claimed application. In the claims, the word "comprising" does not exclude other components or steps, and "a" or "an" does not exclude multiple instances. While different dependent claims may recite certain measures, this does not mean that these measures cannot be combined to produce a good effect.

[0134] Those skilled in the art will understand that all or part of the steps in the various method embodiments of any of the above-described vehicle diagnostic report generation methods can be implemented by a program instructing related hardware. The program can be stored in a computer-readable storage device, which may include: a flash drive, a read-only memory (ROM), a random access memory (RAM), a disk, or an optical disk, etc.

[0135] The embodiments of this application have been described in detail above. Specific examples have been used to illustrate the principles and implementation methods of a vehicle diagnostic report generation method, apparatus, electronic device, and storage medium of this application. The descriptions of the above embodiments are only for the purpose of helping to understand the method and its core ideas of this application. At the same time, for those skilled in the art, based on the ideas of a vehicle diagnostic report generation method, apparatus, electronic device, and storage medium of this application, there will be changes in the specific implementation methods and application scope. Therefore, the content of this specification should not be construed as a limitation of this application.

[0136] This application is described with reference to flowchart illustrations and / or block diagrams of methods, hardware products, and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0137] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0138] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0139] It is understood that any product that is controlled or configured to execute the processing method of the flowchart described in the method embodiment of the vehicle diagnostic report generation method of this application, such as the terminal and computer program product of the above flowchart, falls within the scope of the related products described in this application.

[0140] Obviously, those skilled in the art can make various modifications and variations to the vehicle diagnostic report generation method, apparatus, electronic device, and storage medium provided in this application without departing from the spirit and scope of this application. Therefore, if these modifications and variations of this application fall within the scope of the claims of this application and their equivalents, this application also intends to include these modifications and variations.

Claims

1. A method for generating a vehicle diagnostic report, characterized in that, The method is applied to an intelligent agent, and the method includes: The diagnostic software is invoked to obtain diagnostic report requirements, vehicle information, and vehicle fault codes. The diagnostic report requirements are used to indicate the diagnostic report that needs to be issued. Based on the vehicle information, a functional plugin corresponding to the vehicle information is determined from the plugin library, which includes functional plugins corresponding to different vehicle models; The vehicle fault codes are used to determine the on-board diagnostic system (OBD) protocol, parameter identifier (PID) list, and acquisition strategy from the functional plug-in. Access the vehicle's OBD interface based on the OBD protocol, and obtain the vehicle's first data based on the PID list and the acquisition strategy; Based on the aforementioned functional plugin, the first data is mapped into readable fields to obtain the second data; A diagnostic report is generated based on the aforementioned functional plugin, the diagnostic report requirements, and the second data.

2. The method according to claim 1, characterized in that, The functional plug-in includes an OBD communication adapter and a data acquisition strategy lookup table. The OBD communication adapter defines the OBD protocols supported by the vehicle model corresponding to the functional plug-in. The data acquisition strategy lookup table defines the PID list and acquisition strategy to be read when different fault codes are present. The step of determining the corresponding on-board diagnostic system OBD protocol, PID list, and acquisition strategy from the functional plug-in based on the vehicle fault codes includes: The OBD protocol is determined based on the OBD communication adapter. Based on the vehicle fault codes, the matching PID list and the acquisition strategy are determined from the acquisition strategy lookup table.

3. The method according to claim 1 or 2, characterized in that, The functional plugin includes a data flow semantic mapping table, which is used to map the original PID to a readable field. The process of mapping the first data to a readable field based on the functional plugin to obtain the second data includes: The first data is mapped to a readable field based on the data flow semantic mapping table in the functional plugin to obtain the second data.

4. The method according to claim 1 or 2, characterized in that, The functional plugin includes anomaly detection rules and a report template. The anomaly detection rules are used to determine abnormal data in the second data. The generation of a diagnostic report based on the functional plugin, the diagnostic report requirements, and the second data includes: Based on the diagnostic report requirements, a target report template is determined from the report templates; The diagnostic report is generated based on the anomaly detection rules, the second data, and the target report template.

5. The method according to claim 1 or 2, characterized in that, Accessing the vehicle's OBD interface based on the OBD protocol, and acquiring the vehicle's first data based on the PID list and the acquisition strategy, including: The standard interaction process corresponding to the vehicle information, the PID list, and the acquisition strategy is obtained from the interaction knowledge base, which is used to define the interaction process of the diagnostic software. The system accesses the vehicle's OBD interface based on the OBD protocol and executes the standard interaction process in the diagnostic software to obtain the vehicle's first data.

6. The method according to claim 5, characterized in that, The method further includes: Obtain a task set and the required vehicle models. The task set includes multiple tasks, and each task includes a list of PIDs to be collected and a corresponding collection strategy. Based on the task set and the required vehicle model, the diagnostic software is used to perform task simulation and obtain interface interaction information with the diagnostic software. The interface interaction information is processed to generate standard interaction processes corresponding to each task in the task set and each vehicle in the required vehicle models; An interactive knowledge base is built based on a vehicle model-task structure.

7. The method according to claim 5, characterized in that, The standard interaction process includes multiple consecutive sub-interaction objectives and semantic descriptions and verification conditions corresponding to each sub-objective. The step of executing the standard interaction process in the diagnostic software to obtain the vehicle's first data includes: Obtain the interface adaptation description file corresponding to the diagnostic software. The interface adaptation description file is used to define the implementation methods of page semantic acquisition operation and control matching click operation. S1, based on the current sub-interaction target in the standard interaction process, the current page state of the diagnostic software is perceived through the page semantic acquisition operation, and it is determined whether the current sub-interaction target has been achieved based on the verification conditions of the current sub-interaction target. S2, if not achieved, then in the set of interactive elements corresponding to the current page state, match the target control that is most relevant to the semantic description of the current sub-interaction target, and perform the interaction with the target control by matching the click operation of the control; S3, if achieved, the next sub-interaction target among the multiple consecutive sub-interaction targets is taken as the current sub-interaction target, and in the set of interactive elements corresponding to the current page state, the target control most relevant to the semantic description of the current sub-interaction target is matched, and the interaction between the target control and the target control is executed through the control matching click operation; Repeat steps S1 to S3 until the last sub-interaction goal in the standard interaction process is achieved, and obtain the first data.

8. A vehicle diagnostic report generation device, characterized in that, The device includes: The first processing unit is used to call the diagnostic software to obtain diagnostic report requirements, vehicle information and vehicle fault codes. The diagnostic report requirements are used to indicate the diagnostic report that needs to be issued. The second processing unit is used to determine the functional plugin corresponding to the vehicle information from the plugin library based on the vehicle information. The plugin library includes functional plugins corresponding to different vehicle models. The third processing unit is used to determine the on-board diagnostic system (OBD) protocol, parameter identifier (PID) list, and acquisition strategy from the functional plug-in through the vehicle fault code. The third processing unit is also used to access the vehicle's OBD interface based on the OBD protocol, and to obtain the vehicle's first data based on the PID list and the acquisition strategy. The third processing unit is further configured to map the first data into a readable field based on the functional plugin to obtain the second data; The third processing unit is also used to generate a diagnostic report based on the functional plugin, the diagnostic report requirements, and the second data.

9. An electronic device, the device comprising a processor, a memory, and executable program code stored in the memory, characterized in that, The processor is configured to retrieve the executable program code stored in the memory to perform the method as described in any one of claims 1-7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the method as described in any one of claims 1-7.

Images