Vehicle diagnosis method based on AI agent and related device

Abstract

This application provides a vehicle diagnostic method and related apparatus based on an AI agent. The method includes: acquiring a diagnostic task instruction from a target user; analyzing the diagnostic task instruction to obtain a target diagnostic task; acquiring diagnostic context data of the target vehicle; determining multiple atomic services based on the target diagnostic task and diagnostic context data; each atomic service corresponding to a diagnostic device function; determining an atomic service flowchart based on the multiple atomic services; and executing the atomic service flowchart through a preset AI agent to obtain a target diagnostic result. By parsing the diagnostic task instruction and combining it with the real-time diagnostic context data of the target vehicle, the atomic services of the diagnostic device can be intelligently matched and arranged to form an execution flowchart, which is then driven by the AI ​​agent to execute and output the diagnostic result. This effectively simplifies the diagnostic operation and improves the efficiency of vehicle diagnosis.

Description

Technical Field

[0001] This application relates to the field of vehicle diagnostic technology, and in particular to a vehicle diagnostic method and related apparatus based on an AI agent. Background Technology

[0002] With the increasing level of automotive electronics and intelligence, the number of on-board control units has increased. Although existing diagnostic equipment integrates a wealth of discrete diagnostic functions, it generally adopts a multi-level menu navigation interaction mode, which is cumbersome and time-consuming. Moreover, the diagnostic process is highly dependent on the user's professional experience, and the functions lack intelligent linkage and unified scheduling. It is unable to adaptively adjust the diagnostic process according to the real-time status of the vehicle, making it difficult to adapt to complex diagnostic scenarios and the user's needs for efficient and intelligent use.

[0003] Therefore, improving the efficiency of vehicle diagnostics is an urgent issue that needs to be addressed. Summary of the Invention

[0004] This application provides a vehicle diagnostic method and related apparatus based on an AI agent. By parsing the diagnostic task instructions of the target user and combining the real-time diagnostic context data of the target vehicle, the method intelligently matches and arranges the atomic services of the diagnostic equipment to form an execution flowchart, which is then driven by the AI ​​agent to execute and output the diagnostic results. This effectively simplifies the diagnostic operation and improves the diagnostic efficiency of the vehicle.

[0005] In a first aspect, embodiments of this application provide a vehicle diagnostic method based on an AI agent, the method comprising: Obtain the diagnostic task instructions from the target user; The diagnostic task instructions are analyzed to obtain the target diagnostic task; Obtain diagnostic context data for the target vehicle; Multiple atomic services are determined based on the target diagnostic task and the diagnostic context data; each atomic service corresponds to a diagnostic device function. Determine the atomic service flowchart based on the multiple atomic services; The target diagnostic results are obtained by executing the atomic service flowchart through a preset AI agent.

[0006] Secondly, embodiments of this application provide a vehicle diagnostic device based on an AI agent. The device includes a first acquisition module, an analysis module, a second acquisition module, a first determination module, a second determination module, and an execution module, wherein: The first acquisition module is used to acquire the diagnostic task instructions of the target user; The analysis module is used to analyze the diagnostic task instructions to obtain the target diagnostic task; The second acquisition module is used to acquire diagnostic context data of the target vehicle; The first determining module is used to determine multiple atomic services based on the target diagnostic task and the diagnostic context data; each atomic service corresponds to a diagnostic device function; The second determining module is used to determine the atomic service flowchart based on the plurality of atomic services; The execution module is used to execute the atomic service flowchart through a preset AI agent to obtain the target diagnostic result.

[0007] Thirdly, embodiments of this application provide an electronic device, including a processor, a memory, a communication interface, and one or more programs, wherein the one or more programs are stored in the memory and configured to be executed by the processor, and the programs include instructions for performing steps in any method of the first aspect of this application.

[0008] Fourthly, embodiments of this application provide a computer-readable storage medium storing a computer program for electronic data interchange, wherein the computer program causes a computer to perform some or all of the steps described in any method of the first aspect of this application.

[0009] Fifthly, embodiments of this application provide a computer program product, wherein the computer program product includes a non-transitory computer-readable storage medium storing a computer program operable to cause a computer to perform some or all of the steps described in any method of the first aspect of this application. The computer program product may be a software installation package.

[0010] By implementing the embodiments of this application, the diagnostic task instructions of the target user can be parsed, and combined with the real-time diagnostic context data of the target vehicle, the atomic services of the diagnostic equipment can be intelligently matched and arranged to form an execution flowchart. Then, the AI ​​agent drives the execution and outputs the diagnostic results, which can effectively simplify the diagnostic operation and improve the diagnostic efficiency of the vehicle. Attached Figure Description

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

[0012] Figure 1 This is a system architecture diagram of an intelligent diagnostic interactive system provided in an embodiment of this application; Figure 2 This is a visual schematic diagram of the execution status of an atomic service provided in an embodiment of this application; Figure 3 This is an application environment diagram of an intelligent diagnostic interactive system provided in an embodiment of this application; Figure 4 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application; Figure 5 This is a flowchart illustrating a vehicle diagnostic method based on an AI agent provided in an embodiment of this application; Figure 6 This is a flowchart illustrating an analysis and diagnosis task instruction provided in an embodiment of this application; Figure 7 This is a schematic flowchart of an atomic service execution process provided in an embodiment of this application; Figure 8 This is a block diagram of the functional modules of a vehicle diagnostic device based on an AI agent, provided in an embodiment of this application. Detailed Implementation

[0013] 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.

[0014] 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 or units is not limited to the listed steps or units, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to these processes, methods, products, or apparatuses.

[0015] It should be understood that the term "and / or" in this document is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. Additionally, the character " / " in this document indicates that the preceding and following related objects are in an "or" relationship. In the embodiments of this application, "multiple" refers to two or more.

[0016] In the embodiments of this application, "at least one item" or its similar expression refers to any combination of these items, including any combination of a single item or a plurality of items. "One or more" means one or more, while "multiple" means two or more. For example, "at least one item" of a, b, or c can represent the following seven cases: a, b, c; a and b; a and c; b and c; a, b, and c. Each of a, b, and c can be an element or a set containing one or more elements.

[0017] In this application, the term "connection" refers to various connection methods, such as direct connection or indirect connection, to achieve communication between devices. This application does not impose any limitations on this.

[0018] 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.

[0019] The following is an explanation of the relevant terms used in this application: Vehicle Identification Number (VIN): A unique 17-character code (numbers and uppercase letters) that uniquely identifies a vehicle and distinguishes it from other vehicles.

[0020] Electronic Control Unit (ECU): The core component of an automotive electronic system, responsible for collecting signals from various sensors, performing calculations and judgments through built-in programs, and issuing commands to actuators to control the operation of various vehicle systems.

[0021] With the increasing level of automotive electronics and intelligence, the number of on-board control units has increased. Although existing diagnostic equipment integrates a wealth of discrete diagnostic functions, it generally adopts a multi-level menu navigation interaction mode, which is cumbersome and time-consuming. Moreover, the diagnostic process is highly dependent on the user's professional experience, and the functions lack intelligent linkage and unified scheduling. It is unable to adaptively adjust the diagnostic process according to the real-time status of the vehicle, making it difficult to adapt to complex diagnostic scenarios and the user's needs for efficient and intelligent use.

[0022] Therefore, improving the efficiency of vehicle diagnostics is an urgent issue that needs to be addressed.

[0023] To address the aforementioned issues, this application provides a vehicle diagnostic method and related apparatus based on an AI agent. The method involves: acquiring a diagnostic task instruction from a target user; analyzing the diagnostic task instruction to obtain a target diagnostic task; acquiring diagnostic context data of the target vehicle; determining multiple atomic services based on the target diagnostic task and the diagnostic context data; each atomic service corresponding to a diagnostic device function; determining an atomic service flowchart based on the multiple atomic services; and executing the atomic service flowchart using a preset AI agent to obtain a target diagnostic result.

[0024] It is evident that by parsing the diagnostic task instructions of the target user, combining the real-time diagnostic context data of the target vehicle, intelligently matching and orchestrating the atomic services corresponding to the functions of the diagnostic equipment, obtaining the atomic service flowchart, and then having the AI ​​agent drive the execution and output of diagnostic results, the diagnostic operation can be effectively simplified, thereby improving the diagnostic efficiency of the vehicle.

[0025] For easier understanding, please refer to Figure 1 , Figure 1 This is a system architecture diagram of an intelligent diagnostic interaction system provided in an embodiment of this application. The intelligent diagnostic interaction system is a hierarchical, decoupled agent-driven platform, including an interaction entry layer, a functional service layer, an intelligent scheduling layer, and a learning optimization layer. It can be uniformly scheduled by AI agents to transform discrete diagnostic functions into coherent task-based atomic services.

[0026] The interactive entry layer serves as the sole interface between the target user and the intelligent diagnostic system, replacing traditional multi-level function menus and providing a centralized window for task input and result display. It integrates a natural language understanding module, supporting combined diagnostic tasks via text and voice input or selection of preset processes through graphical cards. This transforms user intent into structured tasks and transmits them to the intelligent scheduling layer, while simultaneously visually displaying diagnostic reports, execution progress, and intermediate data.

[0027] The functional service layer is the foundation for the intelligent diagnostic interaction system to achieve flexible function scheduling. Its core function is to standardize and atomically encapsulate all native, discrete detection, testing, and programming functions within the diagnostic equipment. Each independent minimum functional unit (such as "reading engine control unit fault codes," "performing a test to raise a specified window," or "coding the throttle control unit") is abstracted as an atomic service. Each atomic service has clearly defined input and output interfaces and execution protocols. All atomic services are registered and published through a centralized service registration and management platform, providing a unified, discoverable, and invokeable pool of functional resources to the upper layer. This decouples business logic from function implementation, ensuring the flexibility and scalability of function scheduling.

[0028] The intelligent scheduling layer serves as the central hub of the intelligent diagnostic interaction system. Driven by a large language model fine-tuned using vehicle diagnostic domain knowledge and equipment function libraries, it is primarily responsible for understanding, planning, and dynamically orchestrating diagnostic tasks. This intelligent scheduling layer receives structured tasks from the interaction entry layer, combines them with diagnostic context data of the target vehicle, and uses vehicle diagnostic domain knowledge for reasoning and analysis. It dynamically decomposes and orchestrates complex diagnostic tasks into ordered, executable atomic service flowcharts, clearly defining the execution order, dependencies, and conditional branches between each atomic service. Simultaneously, the AI ​​agent built into this intelligent scheduling layer can invoke the intelligent orchestration engine to execute the atomic service flowcharts, monitor the execution status of each atomic service in real time, and ultimately integrate all diagnostic sub-results to form a target diagnostic result including fault location, cause analysis, and repair suggestions, thus achieving intelligent scheduling and execution of the diagnostic process.

[0029] For easier understanding, please refer to Figure 2 , Figure 2 This is a visualization diagram of the execution status of atomic services provided in an embodiment of this application. The first atomic service points to the second atomic service, and the second atomic service points to the third atomic service, representing the sequence of atomic services executed in logical order after the target diagnostic task is broken down. The arrows clearly indicate the sequential dependencies between the atomic services. The status panel of the first atomic service includes a first execution status, a first real-time progress, and a first key result; the status panel of the second atomic service includes a second execution status, a second real-time progress, and a second key result; and the status panel of the third atomic service includes a third execution status, a third real-time progress, and a third key result. It can be seen that each atomic service has a corresponding status panel on its right, which includes the execution status, real-time progress, and key results. The execution status indicates the current stage of the atomic service (e.g., waiting, executing, successful, failed); the real-time progress indicates the percentage of execution progress of the atomic service, providing a direct understanding of the task's progress; and the key results represent the core intermediate data generated during execution (e.g., read fault codes, data stream values, etc.).

[0030] The learning optimization layer serves as a closed-loop engine driving the continuous evolution of the intelligent diagnostic interaction system, enabling continuous optimization of system capabilities. This layer provides a convenient user feedback interface, collecting user evaluations of the accuracy and usefulness of diagnostic task execution results, as well as specific improvement suggestions. It associates and stores user feedback data with the corresponding task's full-link execution logs (such as user input, atomic service call sequences, and vehicle diagnostic data) to construct a reinforcement learning sample library. The system periodically uses this sample library to perform incremental training or reinforcement learning optimization on the AI ​​agent in the intelligent scheduling layer, continuously improving the AI ​​agent's task planning and process orchestration capabilities, enabling the system to iterate and upgrade, becoming increasingly intelligent with each use in practical applications.

[0031] It is evident that the intelligent diagnostic interaction system, with the intelligent scheduling layer as its core hub, relies on the standardized atomic service resources of the functional service layer. Through the interaction entry layer, it enables convenient interaction between users and the system, and then uses the learning optimization layer to complete continuous iteration. This effectively solves the pain points of traditional diagnostic equipment, such as discrete functions, complex operation, and lack of intelligent scheduling and continuous evolution capabilities. It realizes the intelligent, convenient, and efficient execution of diagnostic tasks. At the same time, through the collaborative linkage of each layer, it ensures the efficiency, adaptability, and scalability of the diagnostic process.

[0032] For easier understanding, please refer to Figure 3 , Figure 3 This diagram illustrates an application environment for an intelligent diagnostic interaction system provided in this application. The target user sends a diagnostic task instruction to the system. This instruction can be text content (e.g., "detect engine fault") or a pre-set task card, serving as the starting point for the entire diagnostic process. The target vehicle transmits diagnostic context data to the system in real time, including static vehicle data, dynamic fault codes, and real-time operating parameters, providing data support for the system's diagnostic execution. Upon receiving the diagnostic task instruction and context data, the system uses its built-in AI agent to schedule atomic services, completing the planning, orchestration, and execution of the diagnostic task. The system generates a target diagnostic result containing fault location, cause analysis, and repair suggestions, and provides feedback to the target user.

[0033] The following is combined Figure 4 The electronic devices in the embodiments of this application will be described. Figure 4 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application, such as... Figure 4 As shown, the electronic device includes one or more processors, a memory, a communication interface, and one or more programs. The processor is connected to the memory and the communication interface via an internal communication bus.

[0034] The processor can be used for: Obtain the diagnostic task instructions from the target user; The diagnostic task instructions are analyzed to obtain the target diagnostic task; Obtain diagnostic context data for the target vehicle; Multiple atomic services are determined based on the target diagnostic task and the diagnostic context data; each atomic service corresponds to a diagnostic device function. Determine the atomic service flowchart based on the multiple atomic services; The target diagnostic results are obtained by executing the atomic service flowchart through a preset AI agent.

[0035] The one or more programs are stored in the aforementioned memory and configured to be executed by the aforementioned processor, and the one or more programs include instructions for performing any step in the above method embodiments.

[0036] The processor can be a central processing unit (CPU), a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (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, cells, 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 unit can be a communication interface, transceiver, transceiver circuit, etc., and the storage unit can be a memory.

[0037] The memory can be volatile or non-volatile, or a combination of both. Non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. Volatile memory can be random access memory (RAM), used as an external cache. By way of example, but not limitation, many forms of random access memory (RAM) are available, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate synchronous DRAM (DDR SDRAM), enhanced synchronous DRAM (ESDRAM), synchronous linked DRAM (SLDRAM), and direct rambus RAM (DR RAM).

[0038] It is understood that the electronic device may include more or fewer structural elements than those shown in the block diagram above, such as a power module, physical buttons, a Wi-Fi module, a speaker, a Bluetooth module, sensors, a display module, etc., without limitation. It is understood that the electronic device may incorporate elements such as... Figure 1 The system architecture described above.

[0039] After understanding the software and hardware architecture of this application, the following will be combined with... Figure 5 This application describes a vehicle diagnostic method based on an AI agent. Figure 5 This is a flowchart illustrating a vehicle diagnostic method based on an AI agent, as provided in an embodiment of this application. The method specifically includes the following steps: Step S501: Obtain the diagnostic task instructions from the target user.

[0040] Specifically, the system receives diagnostic task instructions (such as "perform high-voltage battery insulation test") input by the target user in the form of text, voice, or graphical task cards. Text instructions are natural language diagnostic requests manually entered by the target user in the input box of the interactive interface; voice instructions are voice diagnostic requests entered by the target user through the voice acquisition module of the interactive interface; and graphical task card instructions are standardized diagnostic task instructions selected by the target user from the preset task card list of the interactive interface. The system performs preliminary verification of all types of diagnostic task instructions input by the target user, eliminating invalid, incorrectly formatted, or irrelevant instructions, retaining valid diagnostic task instructions, and completing the instruction reception, thus achieving the acquisition of diagnostic task instructions from the target user.

[0041] Step S502: Analyze the diagnostic task instructions to obtain the target diagnostic task.

[0042] For easier understanding, please refer to Figure 6 , Figure 6 This is a flowchart illustrating an analysis and diagnosis task instruction provided in an embodiment of this application. The specific steps of analyzing the diagnosis task instruction to obtain the target diagnosis task include: A1. Determine the text information corresponding to the diagnostic task instruction; A2. Perform natural language parsing on the text information to obtain core information; the core information includes the diagnostic object, diagnostic type, and diagnostic requirements. A3. Based on the preset task structuring specifications, the diagnostic object, the diagnostic type, and the diagnostic requirements are structured to obtain the target diagnostic task.

[0043] In a specific embodiment, firstly, if the diagnostic task instruction is in the form of voice, the voice recognition module built into the diagnostic device performs real-time voice recognition on the voice instruction input by the target user, converting the voice signal of the voice instruction into standard text information; if the diagnostic task instruction is in the form of a graphical task card, the standard text information corresponding to the card is matched and extracted from the mapping table according to the preset mapping relationship between task cards and standard text instructions; if the diagnostic task instruction is in the form of text, the text content input by the user is directly used as the text information to be parsed.

[0044] Then, the text information is segmented, syntactically analyzed, and semantically understood using a pre-defined natural language processing model to extract the core information required to complete the diagnostic task. This core information includes the diagnostic object, diagnostic type, and diagnostic requirements. The diagnostic object refers to the vehicle system, component, or control unit to be diagnosed, such as the engine, high-voltage battery, anti-lock braking system, throttle control unit, etc.; the diagnostic type refers to the specific diagnostic operation type, such as fault code reading, real-time data stream acquisition, component action testing, code matching, system initialization, insulation testing, etc.; and the diagnostic requirements are the constraints imposed by the user on the diagnostic process or output results, such as limitations on the diagnostic scope, diagnostic depth requirements, output report format, and whether test records need to be generated.

[0045] Next, according to the preset unified task structuring specifications, the extracted core information such as diagnostic objects, diagnostic types, and diagnostic requirements are organized and encapsulated according to fixed field formats to form structured task objects. The target diagnostic task contains standardized fields that can be directly recognized, parsed, and processed by the AI ​​agent, such as task ID, diagnostic object identifier, diagnostic type identifier, diagnostic requirement parameters, and task priority, which are used for subsequent fusion with vehicle diagnostic context data, atomic service matching, and process orchestration.

[0046] It is evident that by uniformly converting diagnostic task instructions into text information and performing natural language parsing and structured processing, core diagnostic information can be accurately extracted, forming standardized target diagnostic tasks. This effectively reduces the user's operational threshold and improves the accuracy and intelligence level of diagnostic task recognition.

[0047] Step S503: Obtain diagnostic context data for the target vehicle.

[0048] The specific steps for obtaining the diagnostic context data of the target vehicle include: B1. Collect first reference data of the target vehicle; the first reference data includes static basic data, dynamic fault data, and real-time operating parameters; B2. Preprocess the first reference data to obtain the second reference data; B3. According to the preset data structuring specifications, the second reference data is processed to obtain the diagnostic context data.

[0049] In a specific embodiment, firstly, a real-time and stable communication connection is established with each on-board control unit of the target vehicle through the OBD-II diagnostic interface. Based on automotive diagnostic communication protocols (such as ISO 14230 and ISO 15765), first reference data of the target vehicle is collected. This first reference data includes, but is not limited to, static basic data, dynamic fault data, and real-time operating parameters. Static basic data: refers to the basic inherent data of the vehicle when it is not running or is idling, including vehicle identification number, model information, year and configuration, engine model, hardware and software versions of each on-board control unit, vehicle factory parameters, etc., used to uniquely identify the target vehicle and match corresponding vehicle diagnostic domain knowledge; Dynamic fault data: refers to fault-related data generated during vehicle operation, including current fault codes, historical fault codes, fault occurrence time, vehicle operating conditions at the time of fault occurrence, fault level, on-board control units and systems associated with the fault, etc., used to locate the direction of vehicle faults; Real-time operating parameters: refers to the operating status data updated in real time during vehicle acquisition, including dynamic operating parameters of various vehicle systems such as engine speed, coolant temperature, throttle opening, intake pressure, fuel injection quantity, battery voltage, braking status, steering angle, etc., used to reflect the current real-time operating status of the vehicle.

[0050] Then, the first reference data is preprocessed to obtain the second reference data. The preprocessing includes, but is not limited to: invalid data removal, data error correction, format standardization, and data noise reduction. The process includes: invalid data removal: filtering and deleting blank data, abnormal extreme value data (such as parameter values ​​exceeding the normal reasonable range), duplicate data, and noisy data generated during the data collection process due to communication interruptions, sensor failures, poor interface contact, etc.; removing redundant data unrelated to vehicle diagnostics; correcting abnormal but correctable data, for example, supplementing missing basic parameters by querying a preset vehicle parameter database based on the vehicle identification code, and correcting real-time operating parameters with small deviations using interpolation to ensure data integrity; format unification: converting the first reference data output from different vehicle control units and different data collection channels according to a preset unified data format, including unified data units, unified data types (such as converting character parameters to standardized numerical or coded data), and unified data precision, eliminating format differences between different data sources; and data denoising: using preset denoising algorithms (such as moving average algorithms) to denoise dynamic data such as real-time operating parameters, filtering out random fluctuations and retaining the true trend of data change.

[0051] Finally, according to vehicle system dimensions (such as engine system, chassis system, body system, electrical system, new energy battery system, etc.), the static basic data, dynamic fault data, and real-time operating parameters in the second reference data are classified and integrated, associating each type of data with its corresponding vehicle system. Then, according to preset data structuring specifications, the classified data are encapsulated into standardized fields, such as a vehicle identification field (associated with static basic data such as VIN and vehicle model), a fault information field (associated with dynamic fault data such as fault codes, fault levels, and fault conditions), and a system operating status field (associated with real-time operating parameters and ECU status of each system). Each field corresponds to a unique field identifier and data description. Related data within the same vehicle system and the same diagnostic scenario are linked and bound. For example, a fault code is bound to the real-time operating parameters and associated ECU at the time of the fault, and the vehicle identification code is bound to the corresponding vehicle basic parameters and diagnostic domain knowledge, forming logical connections between the data. All encapsulated standardized fields and linked data are integrated to form structured diagnostic context data, which can be directly used for subsequent fusion analysis, atomic service matching, and process orchestration with the target diagnostic task.

[0052] It is evident that by comprehensively collecting multi-dimensional vehicle data and performing preprocessing and structuring, accurate, standardized, and directly callable diagnostic context data can be generated, providing reliable data support for subsequent diagnostic task analysis and atomic service matching, thereby improving the accuracy and adaptability of diagnosis.

[0053] Step S504: Determine multiple atomic services based on the target diagnostic task and the diagnostic context data.

[0054] Each atomic service corresponds to a diagnostic device function; the specific steps for determining multiple atomic services based on the target diagnostic task and the diagnostic context data include: C1. Determine the vehicle diagnostic domain knowledge corresponding to the target vehicle; C2. Based on the knowledge in the vehicle diagnostic domain, analyze the target diagnostic task and the diagnostic context data to obtain multiple basic diagnostic operations; C3. Obtain the preset atomic service library; the atomic service library is a pool of callable functional resources formed by standardizing and atomizing the functions of the diagnostic equipment. C4. Select the atomic services corresponding to the multiple basic diagnostic operations from the atomic service library; each basic diagnostic operation corresponds to one atomic service.

[0055] In a specific embodiment, firstly, based on the vehicle model information of the target vehicle, vehicle diagnostic domain knowledge that is fully compatible with the target vehicle is matched and retrieved from a preset vehicle diagnostic domain knowledge base. This vehicle diagnostic domain knowledge includes, but is not limited to: standard diagnostic procedures, fault diagnosis specifications, diagnostic execution logic, diagnostic execution protocol sets, execution preconditions, and operational constraints, which are not specifically limited here.

[0056] Then, based on knowledge of vehicle diagnostics, the target diagnostic task and diagnostic context data are analyzed to obtain the core requirements of the target diagnostic task. Simultaneously, combined with the vehicle's current actual state reflected in the diagnostic context data (such as the presence of fault codes, which systems are malfunctioning, and whether real-time parameters exceed reasonable ranges), the diagnostic direction of the target diagnostic task is defined. Following this diagnostic direction, the target diagnostic task is broken down and analyzed to obtain several basic diagnostic operations.

[0057] Next, a pre-built atomic service library is obtained. This library is a standardized collection of services pre-built and maintained, containing all discrete diagnostic functions of the diagnostic equipment. Essentially, it's a pool of callable functional resources formed by standardizing and atomically encapsulating the diagnostic equipment's functions. Specifically, all native diagnostic functions built into the diagnostic equipment (such as the X431 diagnostic instrument), including fault code reading, real-time data stream acquisition, component action testing, code matching, system initialization, and insulation detection, can be atomically encapsulated according to a unified standardized specification. Each diagnostic function is assigned a unique service ID, and clearly defined input parameters (such as target ECU address, test parameters, etc.), output data format, and execution protocol are defined to ensure that each atomic service can be called independently without dependency conflicts. All encapsulated atomic services are uniformly registered in the atomic service library, forming a functional resource pool that can be uniformly discovered, queried, and called by the AI ​​agent. Furthermore, the atomic service library supports subsequent function updates and service iterations, and can add corresponding atomic services according to the functional upgrades of the diagnostic equipment.

[0058] Next, based on the preset atomic service mapping rules (i.e., each basic diagnostic operation corresponds to one atomic service), each basic diagnostic operation is matched with atomic services in the atomic service library. During the matching process, the vehicle model information and the actual state reflected in the diagnostic context data are combined to further verify whether the matched atomic services are suitable for the current diagnostic scenario and whether they meet the execution prerequisites. Atomic services with insufficient adaptability are eliminated, and atomic services that completely correspond to each basic diagnostic operation are selected. Finally, after all basic diagnostic operations are matched, multiple atomic services that are adapted to the target diagnostic task and the actual state of the target vehicle are obtained.

[0059] As can be seen, by matching the vehicle diagnostic domain knowledge corresponding to the target vehicle, combining the target diagnostic task and diagnostic context data to decompose the appropriate basic diagnostic operations, and accurately matching the corresponding atomic services from the atomic service library, the intelligent mapping between diagnostic tasks and equipment functions is realized, effectively improving the professionalism, adaptability and execution efficiency of the diagnostic process.

[0060] In one possible implementation, each independent basic diagnostic function (e.g., "reading specific ECU fault codes," "performing component action tests," or "performing coding operations") can be encapsulated as a standard atomic service by calling the native interfaces provided by the diagnostic device (such as AndroidIntent, AIDL, or a dedicated SDK). Each atomic service has a unique service ID, standardized input parameter definitions (e.g., target ECU address, test parameters), a clear execution method, and a structured output data format. This metadata is uniformly registered in a service catalog, forming a machine-readable list of device functions. The structured data such as service names, function descriptions, applicable vehicle models, and associated parameters from the above device function list are used as key training corpus, injected into and fine-tuned to the AI ​​agent (i.e., the domain-wide model). This allows the AI ​​agent to obtain specific information about the diagnostic device functions, gain a deeper understanding of the purpose, applicable scenarios, and technical implications of each diagnostic device function, and provide a knowledge foundation for its subsequent intelligent recommendation and orchestration.

[0061] In one possible embodiment, the AI ​​agent can intelligently select multiple relevant atomic services from the atomic service library (i.e., service catalog) based on the task objective, and automatically generate an optimal service execution sequence according to the diagnostic execution logic and diagnostic context data. Then, it can sequentially call each atomic service in the service execution sequence to complete cross-functional collaborative work.

[0062] Specifically, the step of analyzing the target diagnostic task and the diagnostic context data based on the vehicle diagnostic domain knowledge to obtain multiple basic diagnostic operations includes: D1. Obtain the standard diagnostic procedures and troubleshooting specifications corresponding to the knowledge in the vehicle diagnostic field; D2. Decompose the target diagnostic task according to the standard diagnostic process to obtain the first set of diagnostic steps; D3. Filter the first set of diagnostic steps according to the fault diagnosis specifications to obtain the second set of diagnostic steps; D4. Decompose all the diagnostic steps in the second set of diagnostic steps to obtain the multiple basic diagnostic operations.

[0063] In a specific embodiment, firstly, standard diagnostic procedures and troubleshooting specifications related to the target diagnostic task are accurately extracted from the vehicle diagnostic domain knowledge corresponding to the target vehicle. The standard diagnostic procedure is a standardized, end-to-end diagnostic step framework developed by the industry or vehicle manufacturers for the diagnostic object and type corresponding to the target diagnostic task. It clarifies the overall steps, sequence, and core operational directions for completing this type of diagnostic task. For example, for the "high-voltage battery insulation detection" task, its standard diagnostic procedure includes four core steps: "reading battery fault codes, collecting battery insulation value parameters, detecting battery terminal status, and verifying insulation performance." The troubleshooting specifications are the screening criteria supporting the implementation of the diagnostic procedure. They include the correspondence between faults and diagnostic steps, the preconditions for executing diagnostic steps, the priority of troubleshooting for compatible vehicle models, and the criteria for judging invalid diagnostic steps. Furthermore, considering the vehicle model characteristics and common fault patterns of the target vehicle, it clarifies which diagnostic steps are applicable to the current vehicle's fault scenario and which steps can be eliminated based on the actual vehicle condition, providing a clear basis for subsequent diagnostic task breakdown and step selection.

[0064] Then, the core elements of the target diagnostic task (diagnostic object, diagnostic type, diagnostic requirements) are clearly defined and precisely matched with the extracted standard diagnostic process to determine the full-link links in the standard diagnostic process that completely correspond to the target diagnostic task. Next, following the execution order of the standard diagnostic process, the target diagnostic task is broken down layer by layer into several coarse-grained core diagnostic links. Each diagnostic link corresponds to a key operational direction for completing the target diagnostic task, and the links follow the logical connections (sequential order, basic dependencies) of the standard diagnostic process. Finally, all the decomposed coarse-grained core diagnostic links are integrated to form the first diagnostic link set. The diagnostic links in this first diagnostic link set are a coarse-grained framework, not considering the actual state of the target vehicle, and only covering all possible links to complete the target diagnostic task. For example, for the "engine misfire diagnosis" task, the decomposed first diagnostic link set includes six coarse-grained links: "reading engine fault codes, acquiring real-time engine data streams, detecting cylinder pressure, checking the ignition system, checking the fuel supply system, and fault verification."

[0065] Next, during the screening process, based on the actual state of the target vehicle reflected in the diagnostic context data (dynamic fault data, real-time operating parameters, system operating status, etc.), and according to the screening criteria of the fault diagnosis specifications, each diagnostic step in the first set of diagnostic steps is verified and screened one by one. Invalid or incompatible diagnostic steps are eliminated, and diagnostic steps that are suitable for the current vehicle state and meet the diagnostic requirements are retained. The specific screening logic is as follows: First, verify the preconditions for each diagnostic step. If the diagnostic context data shows that the preconditions for the step are not met (e.g., the precondition for the "check cylinder pressure" step is "engine is idling," but real-time operating parameters show that the engine is not started), then the step is removed. Next, based on the "correspondence between faults and diagnostic steps" in the fault diagnosis specification, if the diagnostic context data does not show the corresponding fault characteristics for that diagnostic step (e.g., "check fuel supply system" in the first set of diagnostic steps, but the diagnostic context data shows no fuel-related fault codes and normal fuel injection parameters), then the step is removed. Then, according to the priority criteria of the fault diagnosis specification, select diagnostic steps that match the diagnostic requirements of the target diagnostic task and the vehicle's current fault level, and remove redundant steps with too low priority or irrelevant to core diagnostic needs. Finally, considering the characteristics of the target vehicle, remove diagnostic steps that are explicitly marked in the fault diagnosis specification as not applicable to that vehicle model.

[0066] Then, all the retained diagnostic steps after screening are integrated to form a second set of diagnostic steps. The diagnostic steps in this second set not only conform to the logic of the standard diagnostic process, but also adapt to the actual state of the target vehicle, with no redundancy or invalid steps, and are the core adaptation steps to complete the target diagnostic task.

[0067] Next, each diagnostic step is further broken down into several minimum executable operation units, namely basic diagnostic operations. Each basic diagnostic operation corresponds to a specific, implementable, single diagnostic action, does not contain multiple related operations, and can be completed independently without relying on other operations. For example, the diagnostic step of "reading engine fault codes" is broken down into four basic diagnostic operations: "establishing communication with the engine ECU, sending a fault code reading command, receiving fault code data returned by the ECU, and parsing the meaning of the fault codes." Finally, all the decomposed basic diagnostic operations are verified to ensure that each basic diagnostic operation conforms to the fault diagnosis specifications and diagnostic execution logic, that there are no logical conflicts or repetitions between operations, and that all basic diagnostic operations, when combined in the order of their corresponding diagnostic steps, can completely fulfill all the operational requirements of the second set of diagnostic steps, thereby completely completing all the diagnostic requirements of the target diagnostic task, ultimately resulting in multiple basic diagnostic operations.

[0068] It is evident that by combining standard diagnostic procedures and fault diagnosis specifications, and by breaking down and adapting the target diagnostic tasks in layers, accurate and non-redundant basic diagnostic operations can be obtained, ensuring that the diagnostic logic is rigorous and fits the actual condition of the vehicle, thereby improving the rationality and pertinence of the diagnostic solution.

[0069] Step S505: Determine the atomic service flowchart based on the plurality of atomic services.

[0070] The specific steps of determining the atomic service flowchart based on the plurality of atomic services include: E1. Obtain the diagnostic execution logic and diagnostic execution protocol set corresponding to the vehicle diagnostic domain knowledge; E2. Determine multiple diagnostic execution sequence numbers corresponding to the multiple atomic services according to the diagnostic execution logic; E3. Obtain the multiple diagnostic execution protocols corresponding to the multiple atomic services in the diagnostic execution protocol set; E4. Based on the multiple diagnostic execution sequence numbers and the multiple diagnostic execution protocols, the multiple atomic services are structured and orchestrated to obtain the atomic service flowchart.

[0071] In a specific embodiment, firstly, the diagnostic execution logic and diagnostic execution protocol set matching the target diagnostic task are accurately extracted from the vehicle diagnostic domain knowledge corresponding to the target vehicle. The diagnostic execution logic is the underlying rule system supporting the orderly execution of atomic services. It includes the execution dependencies between atomic services, conditional branching rules, execution priority criteria, and exception handling logic (such as retry mechanisms and alternative solutions after atomic service execution failure). It also associates with the real-time vehicle status in the diagnostic context data, clarifying the subsequent operation guidelines corresponding to different execution results, providing a core basis for determining the execution order of atomic services. The diagnostic execution protocol set is a predefined set of standardized protocols used to drive the execution of atomic services. It covers the communication protocol between the diagnostic device and the vehicle control unit, the calling protocol of atomic services, and data interaction protocols. Each atomic service corresponds to a unique diagnostic execution protocol, clarifying the calling parameters, data transmission format, execution sequence, feedback mechanism, and interface specifications of the atomic service, ensuring that the atomic services can be normally called and stably executed by the intelligent orchestration engine or AI agent.

[0072] Next, the basic diagnostic operations corresponding to the current multiple atomic services are reviewed, and the execution dependencies in the diagnostic execution logic are considered to clarify the execution order constraints of each atomic service (e.g., the "read fault codes" atomic service must be executed before the "data stream acquisition" atomic service, and the "component action test" atomic service can only be executed after the "establish ECU communication" atomic service is completed). Secondly, based on the execution priority criteria in the diagnostic execution logic, and considering the diagnostic requirements of the target diagnostic task (e.g., diagnostic depth, timeliness requirements) and the vehicle status in the diagnostic context data (e.g., fault level, abnormality degree), atomic services without direct dependencies are divided. Execution priority; secondly, according to execution dependencies and priorities, a unique diagnostic execution sequence number is assigned to each atomic service. This sequence number clarifies the execution order of each atomic service in the overall process, and also marks atomic services with conditional branches (e.g., if an atomic service executes successfully, the next service is executed according to the sequence number; if it fails, it jumps to a designated backup atomic service); finally, the diagnostic execution sequence numbers of all atomic services are verified to ensure that the sequence number allocation conforms to the diagnostic execution logic, with no order conflicts or dependency omissions, and that the execution timing of each atomic service is clearly defined, ultimately resulting in multiple diagnostic execution sequence numbers that correspond one-to-one with multiple atomic services.

[0073] Next, the diagnostic execution protocol set is traversed. Based on the unique service ID of each atomic service (pre-assigned during atomic service encapsulation), the diagnostic execution protocol corresponding to that atomic service is precisely matched and extracted from the protocol set. Then, each extracted diagnostic execution protocol undergoes compatibility verification to confirm that the calling parameters, communication specifications, and execution requirements in the protocol are consistent with the vehicle model information, diagnostic context data, and requirements of the target diagnostic task. If there are any discrepancies between protocol parameters and the actual vehicle state, the protocol parameters are adaptively adjusted based on the diagnostic execution logic (e.g., adjusting the communication baud rate and ECU address parameters) to ensure that the diagnostic protocol can adapt to the target vehicle and the current diagnostic scenario. Finally, all verified and adjusted diagnostic execution protocols are organized to obtain multiple diagnostic execution protocols that correspond one-to-one with multiple atomic services.

[0074] Finally, a basic framework for the atomic service flowchart is built. Using the diagnostic execution sequence number as the core clue, multiple atomic services are initially arranged in numerical order to clarify the basic execution chain of each atomic service. Secondly, combining the conditional branching rules and exception handling logic in the diagnostic execution logic, branch nodes, jump nodes, and exception handling nodes are added to the flowchart, marking the subsequent flow path when each atomic service executes successfully, fails, or encounters an exception (e.g., if an atomic service fails, the flowchart jumps to the "retry" node or the "alternative atomic service" node), ensuring that the atomic service flowchart can adapt to different execution scenarios. Thirdly, the diagnostic execution protocol corresponding to each atomic service is associated with the corresponding node in the flowchart, clearly marking the calling parameters, execution protocol identifier, data interaction requirements, and feedback standards of the atomic service in the node. This ensures that the flowchart not only clarifies the execution order but also includes specific execution criteria, resulting in a standardized and structured atomic service flowchart that can be directly recognized, parsed, and executed by AI agents and intelligent orchestration engines, and can fully cover all execution requirements of the target diagnostic task.

[0075] As can be seen, by combining the diagnostic execution logic and the diagnostic execution protocol set, the diagnostic execution sequence number and diagnostic execution protocol corresponding to the atomic service are determined, and the atomic services are structured and orchestrated to generate a standardized and executable atomic service flowchart, ensuring that the diagnostic process is executed in an orderly, efficient and reliable manner.

[0076] Step S506: The atomic service flowchart is executed by a preset AI agent to obtain the target diagnostic result.

[0077] For easier understanding, please refer to Figure 7 , Figure 7 This application provides a schematic flowchart of an atomic service process, wherein the step of executing the atomic service flowchart through a preset AI agent to obtain a target diagnostic result includes the following steps: F1. The AI ​​agent loads the atomic service flowchart to generate multiple call instructions; each call instruction corresponds to an atomic service. F2. Execute the corresponding atomic service according to each of the multiple invocation instructions to diagnose the target vehicle and obtain multiple diagnostic sub-results; F3. Determine the target diagnostic result based on the multiple diagnostic sub-results.

[0078] In a specific embodiment, firstly, an AI agent loads the atomic service flowchart from the intelligent orchestration engine or local storage, parses the atomic service flow, and identifies all atomic service nodes, diagnostic execution sequence numbers, diagnostic execution protocols, and conditional branching rules contained within it. The AI ​​agent can sequentially traverse each atomic service node according to the order of its diagnostic execution sequence number, and generate standardized invocation instructions for each atomic service based on the associated diagnostic execution protocol, input parameters, and diagnostic context data of the target vehicle. These invocation instructions include information such as the atomic service identifier, execution protocol type, target ECU address, diagnostic parameters, data interaction format, and execution timeout threshold, ensuring that the diagnostic equipment can accurately identify and execute the corresponding atomic service. Finally, the AI ​​agent generates multiple invocation instructions, each corresponding to one of the multiple atomic services.

[0079] Then, the AI ​​agent sequentially sends the generated call instructions to the diagnostic device according to the execution order in the atomic service flowchart. Upon receiving the call instruction, the diagnostic device establishes communication with the corresponding vehicle control unit of the target vehicle based on the diagnostic execution protocol in the call instruction, executes the atomic service corresponding to the call instruction, and completes the corresponding diagnostic operation. During the execution of the atomic service, the diagnostic device collects feedback data from the target vehicle in real time and returns the execution status and results to the AI ​​agent. If the conditional branching rules in the flowchart are triggered during execution (such as execution success, execution failure, parameter abnormality, etc.), the AI ​​agent adjusts the subsequent instruction delivery path according to the branch logic to achieve adaptive execution. After each atomic service is completed, the AI ​​agent collects and saves the corresponding diagnostic sub-results, including fault code information, real-time parameter values, action test feedback, status judgment results, etc., ultimately obtaining multiple diagnostic sub-results corresponding one-to-one with multiple atomic services.

[0080] Finally, the AI ​​agent integrates, analyzes, and evaluates the collected diagnostic sub-results. Combining knowledge from the vehicle diagnostic domain, it performs correlation analysis on each sub-result to identify causal relationships between faults, correlations of abnormal parameters, and overall trends in system operation. Following preset diagnostic result aggregation rules, the AI ​​agent summarizes and refines the scattered diagnostic sub-results, forming comprehensive diagnostic information that includes fault location, fault cause analysis, fault level determination, and repair suggestions. This comprehensive diagnostic information is then organized into standardized target diagnostic results, which may include a diagnostic report, fault list, parameter comparison table, and repair plan, used to intuitively present complete diagnostic conclusions and handling suggestions to the target user.

[0081] As can be seen, by loading atomic service flowcharts and generating call instructions to execute atomic services through AI intelligent agents, and then aggregating all diagnostic sub-results, the diagnostic process can be automated and the results can be intelligently integrated, which greatly improves diagnostic efficiency.

[0082] In one possible embodiment, the final task result display page integrates convenient feedback components, such as "Result Evaluation" (e.g., "Accurate / Average / Inaccurate") and a "Feedback" text box. When a target user submits feedback, this evaluation can be strongly correlated and stored with the corresponding complete task execution chain data (user's original input, vehicle context snapshot, AI-recommended or orchestrated service sequences, and execution result logs of each atomic service), forming a high-quality feedback sample. The accumulated feedback samples can be used periodically to retrain the AI ​​agent. For example, focused learning can be conducted on recommendation or orchestration cases marked as "inaccurate" by users to optimize the accuracy of context-based recommendation functions and the logical rationality of cross-service task orchestration, thereby achieving continuous improvement in the overall intelligence level.

[0083] The above primarily describes the solutions of the embodiments of this application from the perspective of the method execution process. It is understood that, in order to achieve the above functions, the electronic device includes corresponding hardware structures and / or software modules for executing each function. Those skilled in the art should readily recognize that, in conjunction with the units and algorithm steps of the various examples described in the embodiments provided herein, this application can be implemented in hardware or a combination of hardware and computer software. Whether a function is executed by hardware or by computer software driving hardware depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0084] This application embodiment can divide the electronic device into functional units according to the above method example. For example, each function can be divided into a separate functional unit, or two or more functions can be integrated into one processing unit. The integrated unit can be implemented in hardware or as a software functional unit. It should be noted that the unit division in this application embodiment is illustrative and only represents one logical functional division. In actual implementation, there may be other division methods.

[0085] When dividing each function into modules according to its corresponding function. Figure 8This is a functional block diagram of a vehicle diagnostic device based on an AI agent provided in an embodiment of this application. The vehicle diagnostic device 800 based on an AI agent includes a first acquisition module 810, an analysis module 820, a second acquisition module 830, a first determination module 840, a second determination module 850, and an execution module 860, wherein: The first acquisition module 810 is used to acquire the diagnostic task instructions of the target user; The analysis module 820 is used to analyze the diagnostic task instructions to obtain the target diagnostic task; The second acquisition module 830 is used to acquire diagnostic context data of the target vehicle; The first determining module 840 is used to determine multiple atomic services based on the target diagnostic task and the diagnostic context data; each atomic service corresponds to a diagnostic device function; The second determining module 850 is used to determine an atomic service flowchart based on the plurality of atomic services; The execution module 860 is used to execute the atomic service flowchart through a preset AI agent to obtain the target diagnostic result.

[0086] Optionally, in analyzing the diagnostic task instructions to obtain the target diagnostic task, the analysis module 820 is specifically used for: Determine the text information corresponding to the diagnostic task instruction; Natural language parsing is performed on the text information to obtain core information; the core information includes the diagnostic object, diagnostic type, and diagnostic requirements. According to the preset task structuring specifications, the diagnostic object, the diagnostic type, and the diagnostic requirements are structured to obtain the target diagnostic task.

[0087] Optionally, in acquiring the diagnostic context data of the target vehicle, the second acquisition module 830 is specifically used for: Collect first reference data of the target vehicle; the first reference data includes static basic data, dynamic fault data and real-time operating parameters. The first reference data is preprocessed to obtain the second reference data; According to the preset data structuring specifications, the second reference data is processed to obtain the diagnostic context data.

[0088] Optionally, in determining multiple atomic services based on the target diagnostic task and the diagnostic context data, the first determining module 840 is specifically configured to: Determine the vehicle diagnostic domain knowledge corresponding to the target vehicle; Based on the knowledge in the vehicle diagnostic domain, the target diagnostic task and the diagnostic context data are analyzed to obtain multiple basic diagnostic operations; Obtain a preset atomic service library; the atomic service library is a pool of callable functional resources formed by standardizing and atomizing the functions of diagnostic equipment. The atomic services corresponding to the multiple basic diagnostic operations are selected from the atomic service library; each basic diagnostic operation corresponds to one atomic service.

[0089] Optionally, in the aspect of analyzing the target diagnostic task and the diagnostic context data based on the vehicle diagnostic domain knowledge to obtain multiple basic diagnostic operations, the first determining module 840 is further specifically used for: Acquire the standard diagnostic procedures and troubleshooting specifications corresponding to the knowledge in the vehicle diagnostic field; The target diagnostic task is decomposed according to the standard diagnostic process to obtain a first set of diagnostic steps; The first set of diagnostic steps is filtered according to the fault diagnosis specifications to obtain the second set of diagnostic steps; The diagnostic steps in the second set of diagnostic steps are broken down to obtain the multiple basic diagnostic operations.

[0090] Optionally, in determining the atomic service flowchart based on the plurality of atomic services, the second determining module 850 is specifically used for: Obtain the diagnostic execution logic and diagnostic execution protocol set corresponding to the vehicle diagnostic domain knowledge; Based on the diagnostic execution logic, multiple diagnostic execution sequence numbers corresponding to the multiple atomic services are determined; Obtain multiple diagnostic execution protocols corresponding to the multiple atomic services in the diagnostic execution protocol set; Based on the multiple diagnostic execution sequence numbers and the multiple diagnostic execution protocols, the multiple atomic services are structured and orchestrated to obtain the atomic service flowchart.

[0091] Optionally, in the step of executing the atomic service flowchart through a preset AI agent to obtain the target diagnostic result, the execution module 860 is specifically used for: The AI ​​agent loads the atomic service flowchart to generate multiple call instructions; each call instruction corresponds to an atomic service. According to each of the multiple invocation instructions, execute its corresponding atomic service to diagnose the target vehicle and obtain multiple diagnostic sub-results; The target diagnostic result is determined based on the multiple diagnostic sub-results.

[0092] It is evident that by parsing the diagnostic task instructions of the target user, combining them with the real-time diagnostic context data of the target vehicle, intelligently matching and orchestrating the atomic services of the diagnostic equipment to form an execution flowchart, and then having the AI ​​agent drive the execution and output of diagnostic results, the diagnostic operation can be effectively simplified, thereby improving the diagnostic efficiency of the vehicle.

[0093] It should be noted that the specific implementation of each operation can be described in the corresponding description of the method embodiments shown above. The vehicle diagnostic device 800 based on AI intelligent agents can be used to execute the method embodiments of this application, and will not be described again here.

[0094] This application also provides a computer-readable storage medium storing a computer program for electronic data interchange, which causes a computer to perform some or all of the steps of any of the methods described in the above method embodiments, wherein the computer includes an electronic device.

[0095] This application also provides a computer program product, which includes a non-transitory computer-readable storage medium storing a computer program operable to cause a computer to perform some or all of the steps of any of the methods described in the above method embodiments. The computer program product may be a software installation package, and the computer may include an electronic device.

[0096] It should be noted that, for the sake of simplicity, the above embodiments are all described as a series of actions. Those skilled in the art should understand that this application is not limited to the described order of actions, as some steps in the embodiments of this application can be performed in other orders or simultaneously. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions, steps, modules, or units involved are not necessarily essential to the embodiments of this application.

[0097] In the above embodiments, the descriptions of each embodiment in this application have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions in other embodiments.

[0098] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. This program can be stored in a computer-readable storage medium, and when executed, it can include the processes described in the above method embodiments. The aforementioned storage medium includes various media capable of storing program code, such as ROM or random access memory (RAM), magnetic disks, or optical disks.

[0099] The steps of the methods or algorithms described in the embodiments of this application can be implemented in hardware or by a processor executing software instructions. The software instructions can consist of corresponding software modules, which can be stored in RAM, flash memory, ROM, EPROM, electrically erasable programmable read-only memory (EEPROM), registers, hard disk, portable hard disk, read-only optical disk (CD-ROM), or any other form of storage medium well known in the art. An exemplary storage medium is coupled to a processor, enabling the processor to read information from and write information to the storage medium. Of course, the storage medium can also be a component of the processor. The processor and storage medium can reside in an ASIC. Furthermore, the ASIC can reside in a terminal device or management device. Alternatively, the processor and storage medium can exist as discrete components in the terminal device or management device.

[0100] Those skilled in the art will recognize that, in one or more of the examples above, the functions described in the embodiments of this application can be implemented, in whole or in part, by software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product. This computer program product includes one or more computer instructions. When these computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in 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. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium accessible to a computer or a data storage device such as a server or data center that integrates one or more available media. The available media can be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., digital video discs (DVDs)), or semiconductor media (e.g., solid-state disks (SSDs)).

[0101] The modules / units included in the various devices and products described in the above embodiments can be software modules / units, hardware modules / units, or a combination of both. For example, for devices and products applied to or integrated into a chip, all modules / units can be implemented using hardware methods such as circuits, or at least some modules / units can be implemented using software programs that run on a processor integrated within the chip, while the remaining (if any) modules / units can be implemented using hardware methods such as circuits. For devices and products applied to or integrated into a chip module, all modules / units can be implemented using hardware methods such as circuits. Different modules / units can be located in the same component (e.g., chip, circuit module, etc.) or different components of the chip module, or at least some modules / units can be implemented using hardware methods such as circuits. The implementation is achieved through a software program that runs on the processor integrated within the chip module. The remaining modules / units (if any) can be implemented using hardware methods such as circuits. For various devices and products applied to or integrated into terminal equipment, each of their modules / units can be implemented using hardware methods such as circuits. Different modules / units can be located in the same component (e.g., chip, circuit module, etc.) or different components within the terminal equipment. Alternatively, at least some modules / units can be implemented through a software program that runs on the processor integrated within the terminal equipment, while the remaining modules / units (if any) can be implemented using hardware methods such as circuits.

[0102] The specific embodiments described above further illustrate the purpose, technical solution, and beneficial effects of the embodiments of this application. It should be understood that the above descriptions are merely specific embodiments of the embodiments of this application and are not intended to limit the protection scope of the embodiments of this application. Any modifications, equivalent substitutions, improvements, etc., made on the basis of the technical solutions of the embodiments of this application should be included within the protection scope of the embodiments of this application.

Claims

1. A vehicle diagnostic method based on an AI agent, characterized in that, The method includes: Obtain the diagnostic task instructions from the target user; The diagnostic task instructions are analyzed to obtain the target diagnostic task; Obtain diagnostic context data for the target vehicle; Multiple atomic services are determined based on the target diagnostic task and the diagnostic context data; each atomic service corresponds to a diagnostic device function. Determine the atomic service flowchart based on the multiple atomic services; The target diagnostic results are obtained by executing the atomic service flowchart through a preset AI agent.

2. The method as described in claim 1, characterized in that, The process of analyzing the diagnostic task instructions to obtain the target diagnostic task includes: Determine the text information corresponding to the diagnostic task instruction; Natural language parsing is performed on the text information to obtain core information; the core information includes the diagnostic object, diagnostic type, and diagnostic requirements. According to the preset task structuring specifications, the diagnostic object, the diagnostic type, and the diagnostic requirements are structured to obtain the target diagnostic task.

3. The method as described in claim 2, characterized in that, The acquisition of diagnostic context data for the target vehicle includes: Collect first reference data of the target vehicle; the first reference data includes static basic data, dynamic fault data and real-time operating parameters. The first reference data is preprocessed to obtain the second reference data; According to the preset data structuring specifications, the second reference data is processed to obtain the diagnostic context data.

4. The method as described in claim 1, characterized in that, The step of determining multiple atomic services based on the target diagnostic task and the diagnostic context data includes: Determine the vehicle diagnostic domain knowledge corresponding to the target vehicle; Based on the knowledge in the vehicle diagnostic domain, the target diagnostic task and the diagnostic context data are analyzed to obtain multiple basic diagnostic operations; Obtain a preset atomic service library; the atomic service library is a pool of callable functional resources formed by standardizing and atomizing the functions of diagnostic equipment. The atomic services corresponding to the multiple basic diagnostic operations are selected from the atomic service library; each basic diagnostic operation corresponds to one atomic service.

5. The method as described in claim 4, characterized in that, Based on the knowledge in the vehicle diagnostic domain, the target diagnostic task and the diagnostic context data are analyzed to obtain multiple basic diagnostic operations, including: Acquire the standard diagnostic procedures and troubleshooting specifications corresponding to the knowledge in the vehicle diagnostic field; The target diagnostic task is decomposed according to the standard diagnostic process to obtain a first set of diagnostic steps; The first set of diagnostic steps is filtered according to the fault diagnosis specifications to obtain the second set of diagnostic steps; The diagnostic steps in the second set of diagnostic steps are broken down to obtain the multiple basic diagnostic operations.

6. The method as described in claim 4, characterized in that, The step of determining the atomic service flowchart based on the plurality of atomic services includes: Obtain the diagnostic execution logic and diagnostic execution protocol set corresponding to the vehicle diagnostic domain knowledge; Based on the diagnostic execution logic, multiple diagnostic execution sequence numbers corresponding to the multiple atomic services are determined; Obtain multiple diagnostic execution protocols corresponding to the multiple atomic services in the diagnostic execution protocol set; Based on the multiple diagnostic execution sequence numbers and the multiple diagnostic execution protocols, the multiple atomic services are structured and orchestrated to obtain the atomic service flowchart.

7. The method as described in claim 6, characterized in that, The step of executing the atomic service flowchart through a preset AI agent to obtain the target diagnostic result includes: The AI ​​agent loads the atomic service flowchart to generate multiple call instructions; each call instruction corresponds to an atomic service. According to each of the multiple invocation instructions, execute its corresponding atomic service to diagnose the target vehicle and obtain multiple diagnostic sub-results; The target diagnostic result is determined based on the multiple diagnostic sub-results.

8. A vehicle diagnostic device based on an AI intelligent agent, characterized in that, The device includes a first acquisition module, an analysis module, a second acquisition module, a first determination module, a second determination module, and an execution module, wherein: The first acquisition module is used to acquire the diagnostic task instructions of the target user; The analysis module is used to analyze the diagnostic task instructions to obtain the target diagnostic task; The second acquisition module is used to acquire diagnostic context data of the target vehicle; The first determining module is used to determine multiple atomic services based on the target diagnostic task and the diagnostic context data; each atomic service corresponds to a diagnostic device function; The second determining module is used to determine the atomic service flowchart based on the plurality of atomic services; The execution module is used to execute the atomic service flowchart through a preset AI agent to obtain the target diagnostic result.

9. An electronic device, characterized in that, include: Processor, memory, communication interface, and one or more programs; The one or more programs are stored in the memory and configured to be executed by the processor, the programs including instructions for performing the steps of the method as described in any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, the computer program including program instructions that, when executed by a processor, cause the processor to perform the method as described in any one of claims 1-7.

Images