Vehicle fault diagnosis method and device, electronic equipment and storage medium

Abstract

The invention discloses a vehicle fault diagnosis method and device, electronic equipment and a storage medium, and the method comprises the steps: firstly obtaining the voice description information of a target user for a target vehicle, and then determining the vehicle feature information and fault feature information corresponding to the target vehicle based on the voice description information, determining k electronic control units needing fault diagnosis in the target vehicle based on the fault feature information, and determining n network diagnosis protocols based on the vehicle feature information and the k electronic control units, obtaining first fault data corresponding to the k electronic control units based on the n network diagnosis protocols, and finally performing fault diagnosis on the k electronic control units based on the first fault data to obtain a first fault diagnosis result. According to the embodiment of the invention, the efficiency of vehicle fault diagnosis is improved.

Description

Technical Field

[0001] This invention relates to the field of vehicle fault diagnosis technology, and in particular to a vehicle fault diagnosis method, device, electronic equipment and storage medium. Background Technology

[0002] With the increasing level of automotive electronics and intelligence, the number of on-board electronic control units (ECUs) is increasing and their functions are becoming more complex. Traditional vehicle fault diagnosis methods rely on the experience and judgment of repair personnel, manually selecting network diagnostic protocols through diagnostic equipment and then performing fault detection on the ECUs. However, manually selecting network diagnostic protocols is inefficient. Different vehicle models and different ECUs are often compatible with different network diagnostic protocols. Incorrect network diagnostic protocol matching will directly lead to the inability to obtain effective fault data, resulting in low vehicle fault diagnosis efficiency. Therefore, how to improve the efficiency of vehicle fault diagnosis is an urgent problem to be solved. Summary of the Invention

[0003] This application provides a vehicle fault diagnosis method, apparatus, electronic device, and storage medium, which improves the efficiency of vehicle fault diagnosis.

[0004] In a first aspect, embodiments of this application provide a vehicle fault diagnosis method, including: Obtain the target user's voice description information for the target vehicle; Based on the voice description information, determine the vehicle characteristic information and fault characteristic information corresponding to the target vehicle; Based on the fault characteristic information, k electronic control units in the target vehicle that require fault diagnosis are identified; k is an integer greater than 1. Based on the vehicle characteristic information and the k electronic control units, n network diagnostic protocols are determined; n is an integer greater than 1. The first fault data corresponding to the k electronic control units is obtained based on the n network diagnostic protocols; Based on the first fault data, fault diagnosis is performed on the k electronic control units to obtain the first fault diagnosis result.

[0005] Secondly, embodiments of this application provide a vehicle fault diagnosis device, the device comprising: an acquisition unit and a processing unit; The acquisition unit is used to acquire the voice description information of the target user for the target vehicle; The processing unit is used to determine the vehicle feature information and fault feature information corresponding to the target vehicle based on the voice description information; Based on the fault characteristic information, k electronic control units in the target vehicle that require fault diagnosis are identified; k is an integer greater than 1. Based on the vehicle characteristic information and the k electronic control units, n network diagnostic protocols are determined; n is an integer greater than 1. The first fault data corresponding to the k electronic control units is obtained based on the n network diagnostic protocols; Based on the first fault data, fault diagnosis is performed on the k electronic control units to obtain the first fault diagnosis result.

[0006] Thirdly, embodiments of the present invention 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 to cause the electronic device to perform the method as described in the first aspect.

[0007] Fourthly, embodiments of the present invention provide a computer-readable storage medium storing a computer program that is executed by a processor to implement the method as described in the first aspect.

[0008] Fifthly, embodiments of the present invention provide a computer program product including a non-transitory computer-readable storage medium storing a computer program, such that a computer performs the method as described in the first aspect.

[0009] Implementing the embodiments of the present invention has the following beneficial effects: As can be seen, the vehicle fault diagnosis method described in this embodiment of the invention first obtains voice description information of the target user regarding the target vehicle, then determines vehicle feature information and fault feature information corresponding to the target vehicle based on the voice description information, then determines the k electronic control units (ECUs) in the target vehicle that require fault diagnosis based on the fault feature information, then determines n network diagnostic protocols based on the vehicle feature information and the k ECUs, then obtains first fault data corresponding to the k ECUs based on the n network diagnostic protocols, and finally performs fault diagnosis on the k ECUs based on the first fault data to obtain a first fault diagnosis result. Using the embodiments of this application improves the efficiency of vehicle fault diagnosis. Attached Figure Description

[0010] To more clearly illustrate the technical solutions in the embodiments of this application or the background art, the accompanying drawings used in the embodiments of this application or the background art will be described below.

[0011] Figure 1 This is a schematic diagram of the structure of a vehicle fault diagnosis system provided in an embodiment of this application; Figure 2 This is a flowchart of a vehicle fault diagnosis method provided in an embodiment of this application; Figure 3 This is a flowchart of determining n network diagnostic protocols provided in an embodiment of this application; Figure 4 This is a flowchart of an embodiment of the present application for determining the matching status corresponding to a network diagnostic protocol; Figure 5 This is a flowchart of determining m network diagnostic protocols provided in an embodiment of this application; Figure 6 This is a block diagram of an architecture for determining a second fault diagnosis result provided in an embodiment of this application; Figure 7 This is a schematic diagram of the structure of a vehicle fault diagnosis device provided in an embodiment of this application; Figure 8 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0012] 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 a part of the embodiments of the present application, and not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present application.

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

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

[0015] Please see Figure 1 , Figure 1This is a schematic diagram of a vehicle fault diagnosis system provided in an embodiment of this application. The vehicle fault diagnosis system 10 includes a diagnostic device 101 and a target vehicle 102. The diagnostic device 101 establishes a communication connection with the target vehicle 102 to perform fault diagnosis operations on the target vehicle 102.

[0016] In this embodiment, the diagnostic device 101 acquires voice description information from a target user regarding a target vehicle 102. Then, based on the voice description information, it determines vehicle characteristic information and fault characteristic information corresponding to the target vehicle. Next, based on the fault characteristic information, it identifies the k electronic control units (ECUs) in the target vehicle that require fault diagnosis. Then, based on the vehicle characteristic information and the k ECUs, it determines n network diagnostic protocols. Next, based on the n network diagnostic protocols, it acquires first fault data corresponding to the k ECUs. Finally, based on the first fault data, it performs fault diagnosis on the k ECUs to obtain a first fault diagnosis result. Through the collaborative work of the diagnostic device 101 and the target vehicle 102 in the vehicle fault diagnosis system 10, the diagnostic object and diagnostic protocol are directly located using voice description information, avoiding the time-consuming and inefficient drawbacks of manual parameter selection, thus improving the efficiency of vehicle fault diagnosis.

[0017] It should be explained that, in this embodiment, the diagnostic device 101 is the core carrier for realizing the entire process of vehicle fault diagnosis, including a hardware and software integrated system with an automotive fault diagnostic instrument at its core, capable of completing all key operations from information collection and data processing to fault diagnosis. The diagnostic device 101 has voice information collection capabilities, enabling it to acquire voice descriptions of the target vehicle 102 from the target user, facilitating convenient input of fault information. Then, the device's built-in data processing module can parse the collected voice descriptions, extracting and determining the corresponding vehicle characteristic information and fault characteristic information. Vehicle characteristic information may include key parameters such as the vehicle's brand and model, production year, power type, and configuration version. Fault characteristic information covers the fault phenomena described by the user, the time of occurrence, and triggering conditions. Subsequently, based on the parsed fault characteristic information, the diagnostic device 101 can automatically match and determine the faults in the target vehicle that require diagnosis. The system diagnoses k electronic control units (ECUs) without requiring manual screening of each ECU, significantly reducing diagnostic preparation time. Based on the identified vehicle characteristics and the k ECUs, the device further matches n compatible network diagnostic protocols. These n protocols are crucial for data communication with the ECUs, ensuring the accuracy and compatibility of fault data collection. The device then establishes a communication connection with the target vehicle's ECU through these n protocols to obtain the corresponding initial fault data. Finally, relying on its built-in fault diagnosis algorithm, the device analyzes and processes the collected initial fault data to obtain the initial fault diagnosis result. It is important to note that the automotive fault diagnostic instrument is a core component of the diagnostic equipment 101 and is the user-operated terminal tool.

[0018] Please see Figure 2 , Figure 2 This is a flowchart of a vehicle fault diagnosis method provided in an embodiment of this application, including but not limited to the following steps: S201: Obtain the target user's voice description information for the target vehicle.

[0019] In this embodiment, the voice description information of the target user regarding the target vehicle is all the content related to the target vehicle's fault expressed by the target user in voice form. This content can include the specific manifestations of the vehicle fault, such as abnormal noises during engine operation, the amplitude of vehicle body vibration during driving, and the illumination status of warning indicator lights on the dashboard. It can also include the specific scenario in which the fault occurs, such as the fault triggering situation when the target vehicle is in the starting, idling, acceleration, or deceleration phase. Furthermore, it can include the duration and frequency of the fault, as well as any special operations performed before the fault occurred. Additionally, it includes vehicle characteristic information, such as the vehicle's brand and model, production year, mileage, power type, and vehicle configuration. This information serves as the initial input data for vehicle fault diagnosis, providing a foundation for subsequent extraction of vehicle characteristic information and fault characteristic information.

[0020] The core of the voice-based information exchange between the target user and the target vehicle relies on a voice interaction system. This system typically consists of hardware and software. The hardware includes a voice acquisition device and a voice output device. The voice acquisition device is usually a vehicle-mounted microphone, which can be installed on the steering wheel, center console, or roof of the vehicle to accurately capture the target user's voice signal. The voice output device is a vehicle-mounted speaker, used to provide feedback and interactive prompts to the target user. The software includes a voice recognition module, a voice synthesis module, and an interaction control module. The entire voice interaction process is as follows: First, the interaction control module issues voice prompts to the target user through the vehicle-mounted speaker, guiding the user to describe the vehicle's fault condition and related vehicle attributes. Then, the target user moves closer to the voice acquisition device as prompted and clearly speaks... The voice acquisition device captures vehicle-related information such as vehicle malfunctions and vehicle characteristics like brand, model, and production year. The captured voice signal is converted into an electrical signal and transmitted to the voice recognition module. The voice recognition module performs noise reduction and feature extraction on the electrical signal, converting it into text information. Simultaneously, the interactive control module uses a voice synthesis module to convert the reception status into voice feedback to the target user, informing them that the voice information has been successfully received. If the voice signal is unclear or ambiguous, especially if vehicle characteristic information or malfunction information is missing, the interactive control module will trigger a secondary prompt, guiding the user to supplement or re-describe the relevant content. This completes the exchange of voice description information between the target user and the target vehicle. The entire process requires no manual operation from the user, improving the convenience and efficiency of information collection.

[0021] S202: Determine the vehicle feature information and fault feature information corresponding to the target vehicle based on the voice description information.

[0022] In this embodiment, determining the vehicle feature information and fault feature information corresponding to the target vehicle based on the voice description information involves using intelligent algorithms to perform structured parsing and information classification of the user-input voice text data. This step relies on speech recognition technology and semantic analysis models. First, the collected voice signal is converted into processable text content. Then, using preset keyword recognition rules and a fault association knowledge base, the text content is analyzed sentence by sentence to filter out content related to the vehicle's own attributes and content related to the fault phenomenon, which are respectively classified as vehicle feature information and fault feature information. During the parsing process, the system performs semantic completion for ambiguous expressions. For example, if a user mentions that a certain car model has a fault, the system will match the corresponding vehicle attribute range by combining a database of common car models. If the information described by the user is missing, the system will also trigger interactive prompts to guide the user to supplement key content. The final output vehicle feature information and fault feature information can provide accurate basis for subsequent identification of the electronic control unit to be diagnosed and selection of network diagnostic protocol.

[0023] Vehicle characteristic information is fundamental information related to the attributes of the target vehicle itself. It is key data for distinguishing different individual vehicles and determining the scope of diagnosis. The information mainly includes the vehicle's brand, model, production year, and mileage. This information reflects the vehicle's basic specifications and service life. It also includes the vehicle's power type, such as fuel vehicles, new energy vehicles, and hybrid models, as well as the vehicle's configuration information, such as the version of the electronic control system and the model of the on-board diagnostic equipment. In addition, it also includes the vehicle's daily use environment and maintenance status, such as whether the vehicle is driven on urban or rural roads, the vehicle's maintenance cycle, and the date of the most recent maintenance. This information can help the diagnostic system determine whether the fault is related to the vehicle's service life, configuration differences, or maintenance status.

[0024] Fault characteristic information is core information directly related to the fault phenomena of the target vehicle and is the key basis for locating the root cause of the fault. It mainly includes the specific manifestation of the vehicle fault, such as abnormal noises when the engine is running, vibrations of the vehicle body during driving, the type and timing of the instrument panel warning lights, the specific scenario in which the fault occurred, such as whether the fault was triggered during the vehicle start-up, idling, acceleration, or deceleration phases, the external environment at the time of the fault, such as temperature, humidity, and road conditions, as well as the duration of the fault, the frequency of the fault occurrence, whether it is intermittent or frequent, and any special operations performed before the fault occurred, such as whether there was aggressive driving or the addition of unconventional fuel before the fault occurred.

[0025] S203: Based on the fault characteristic information, determine the k electronic control units in the target vehicle that require fault diagnosis.

[0026] In this embodiment, the electronic control unit (ECU) in the vehicle is the core electronic device for the automated control and data management of various vehicle systems. Also known as an on-board electronic control unit, it is an embedded computer system integrating core components such as a microprocessor, memory, input / output interfaces, and analog-to-digital converters. Different ECUs correspond to different functional modules in the vehicle. For example, the engine control unit is responsible for regulating key parameters such as fuel injection quantity and ignition timing to ensure efficient and stable engine operation; the transmission control unit manages shift logic and transmission efficiency; the anti-lock braking system (ABS) control unit monitors wheel speed and adjusts braking force distribution; the vehicle stability system control unit ensures stable vehicle posture during driving; the air conditioning control unit regulates the interior temperature and airflow; and there are various dedicated ECUs responsible for functions such as airbag triggering, tire pressure monitoring, and lighting control. These ECUs are interconnected through the on-board network bus, transmitting and exchanging data in real time to collectively constitute the vehicle's electronic control system. In this embodiment, determining the k ECUs requiring diagnosis based on fault characteristic information involves combining the fault phenomena described by the target user, such as engine vibration, brake failure, and air conditioning malfunction, matching the corresponding functional modules, and then identifying one or more ECUs responsible for that function.

[0027] First, the input fault characteristic information is comprehensively broken down to extract key elements such as the core fault manifestations, fault occurrence scenarios, and fault triggering conditions of the target vehicle. Then, these key elements are compared one by one with a massive amount of data stored in a related knowledge base. This knowledge base pre-includes the functions and responsibilities of various electronic control units (ECUs) of different vehicle models, along with their corresponding typical fault characteristics. For example, the engine ECU corresponds to fault characteristics such as insufficient power and abnormal fuel consumption; the transmission ECU corresponds to fault characteristics such as shift jerking and gear failure; and the vehicle stability control unit corresponds to fault characteristics such as driving deviation and abnormal braking. It also includes fault association logic when multiple ECUs work together. Subsequently, the system filters out ECUs that are directly or indirectly related to the current fault characteristic information based on the comparison results. It should be noted that many vehicle faults are not caused by a single ECU malfunction, but rather by abnormal signal interaction or failure of coordination between multiple ECUs. Finally, the filtered ECUs are integrated to obtain a list of k ECUs to be diagnosed. This entire process accurately narrows down the fault diagnosis scope, avoiding indiscriminate checking of all ECUs in the vehicle, and effectively improving the efficiency and accuracy of fault diagnosis.

[0028] For example, if the target user reports the following fault characteristics: continuous engine vibration after vehicle start-up, insufficient power during acceleration, and engine malfunction indicator light on the dashboard, the diagnostic equipment, after analyzing this information, will combine the correspondence between the fault characteristics and the functions of the electronic control units (ECUs) to identify the ECUs that need to be diagnosed. First, the engine control unit (ECU) directly responsible for engine operation control, as its failure may cause vibration and power problems. Second, the fuel control unit corresponding to the fuel injection system, as abnormal fuel supply will directly affect engine power output. Third, the ignition control unit of the ignition system, as inaccurate ignition timing or insufficient ignition energy will cause engine vibration. In addition, the signal processing units corresponding to the sensors responsible for monitoring the engine's operating status also need to be included in the diagnostic scope to avoid misdiagnosis due to abnormal sensor signals. These four identified ECUs are the k ECUs that need to be diagnosed.

[0029] S204: Determine n network diagnostic protocols based on the vehicle characteristic information and the k electronic control units.

[0030] In this embodiment, the network diagnostic protocol is a standardized set of rules for data communication and fault information exchange between the diagnostic equipment and the various electronic control units (ECUs) of the vehicle. It specifies the format, rate, command type, and response method for data transmission between the diagnostic equipment and the ECUs, ensuring that a stable and reliable connection can be established and information exchange can be completed. Different vehicle brands, models, and ECUs correspond to different network diagnostic protocols. These protocols cover various functional commands such as data acquisition commands, fault code reading commands, and parameter configuration commands. After determining the vehicle characteristic information of the target vehicle and the ECUs to be diagnosed, the diagnostic equipment will match the corresponding network diagnostic protocol and send a data acquisition request to the ECUs through the protocol. The ECUs will then feed back their own operating parameters, fault status, and other data according to the format agreed upon in the protocol. This data is the core basis for the diagnostic equipment to perform fault analysis. A suitable network diagnostic protocol can ensure the accuracy and integrity of data transmission and avoid data loss or transmission failure due to mismatched communication rules.

[0031] When determining n network diagnostic protocols based on the vehicle feature information and the k electronic control units, firstly, m network diagnostic protocols compatible with the target vehicle are selected based on the vehicle feature information, where m is an integer greater than n. This is because vehicles of different brands, models, production years, and configurations support different network diagnostic protocols. The brand and model in the vehicle feature information directly limits the approximate range of protocols, while the production year and configuration further narrow down the selection range, ensuring that the selected m protocols are theoretically compatible with the target vehicle. Then, the matching status of each of the selected m network diagnostic protocols with the k electronic control units to be diagnosed is analyzed one by one. The matching status is divided into two types: matched and mismatched. The judgment is based on the... Whether the network diagnostic protocol supports establishing a communication connection with the corresponding electronic control unit and reading fault data. For example, some protocols are only applicable to engine electronic control units, while others are compatible with multiple types such as transmission and vehicle stability control units. Each network diagnostic protocol corresponds to an overall matching state. If a certain protocol can establish effective communication with at least one of the k electronic control units and meet the data reading requirements, it is determined to be a match; otherwise, it is a mismatch. Finally, based on the obtained m matching states, all protocols that match the k electronic control units are selected from the m protocols and integrated to obtain the final n network diagnostic protocols, which can adapt to the target vehicle and meet the fault data collection requirements of the k electronic control units.

[0032] S205: Obtain the first fault data corresponding to the k electronic control units based on the n network diagnostic protocols.

[0033] In this embodiment, the diagnostic device first establishes a connection with the vehicle's onboard communication bus. Following the communication rules of n predetermined network diagnostic protocols, it systematically interacts with k electronic control units (ECUs) to be diagnosed. First, the diagnostic device generates corresponding data acquisition commands based on the command format of each network diagnostic protocol. Different network diagnostic protocols correspond to different command specifications and data transmission formats, requiring targeted adaptation for effective communication. Then, the diagnostic device sequentially sends these commands to the corresponding ECUs. For multiple ECUs supporting the same network diagnostic protocol, adaptation commands can be sent in batches to improve acquisition efficiency. Next, upon receiving the commands, the k ECUs retrieve their stored operating data, including real-time operating parameters, fault codes, historical fault records, sensor feedback data, and other core information related to fault diagnosis. This data is then encapsulated according to the format required by the corresponding network diagnostic protocol and transmitted back to the diagnostic device via the onboard communication bus. Upon receiving the transmitted data, the diagnostic device verifies the data to confirm its integrity and accuracy, eliminating invalid data caused by communication interference or protocol incompatibility, thereby obtaining the first fault data.

[0034] S206: Based on the first fault data, perform fault diagnosis on the k electronic control units to obtain the first fault diagnosis result.

[0035] In this embodiment, the first collected fault data is preprocessed. This preprocessing includes data cleaning and data standardization. Data cleaning mainly removes invalid and outlier values ​​from the data, such as erroneous data caused by communication interference or missing data caused by data acquisition interruption. Data standardization converts heterogeneous data collected by different network diagnostic protocols into a unified format to ensure data comparability. Then, the preprocessed first fault data is compared with a preset fault diagnosis benchmark database. The fault diagnosis benchmark database stores the parameter threshold ranges of different types of electronic control units under normal operating conditions and typical data characteristics corresponding to various faults, such as the fuel injection pressure in the normal speed range of the engine electronic control unit. The system first analyzes the fault data of k electronic control units, including the force range and shift signal parameters of the transmission electronic control unit. Then, it analyzes the fault data of each unit one by one to determine whether the operating parameters of each unit exceed the normal threshold range. At the same time, it identifies whether the data contains typical fault characteristics. For data anomalies of a single electronic control unit, it directly locates the specific fault type of that unit. For data anomalies of multiple electronic control units that are related, it combines the signal interaction logic and collaborative working mechanism between electronic control units to analyze the root unit of the fault and its derivative effects. Finally, it integrates the data analysis results of all electronic control units to obtain the first fault diagnosis result, which includes the location, fault type, fault severity, and fault correlation of the k electronic control units.

[0036] When the diagnostic device performs fault diagnosis on the k electronic control units based on the first fault data, the diagnostic device first receives the first fault data collected from the k electronic control units through n network diagnostic protocols. This data includes the operating parameters, status codes, fault codes, and real-time working data streams of each electronic control unit. Subsequently, the data preprocessing module built into the device cleans these raw data, filtering out invalid data and abnormal noise caused by communication interference, so as to ensure the accuracy and validity of the data. Next, the device will call a preset fault diagnosis algorithm to compare the preprocessed fault data with the standard data model stored in local resources. This standard data model covers the parameter threshold range and operating characteristic baseline of each electronic control unit of the target vehicle model under normal operating conditions. At the same time, the diagnostic device will combine fault feature information and focus on analyzing the data dimensions related to the fault phenomenon described by the user. For example, if the user reports engine vibration, it will focus on the deviation of key parameters such as fuel injection quantity and ignition timing of the engine control unit. Then, the diagnostic device will calculate the deviation value between the fault data and the standard model, match the correspondence between fault types and causes in the fault diagnosis knowledge base, and determine whether each electronic control unit has a fault, the specific type of fault, and the possible causes. Finally, the diagnostic device will integrate these diagnostic analysis results to form a structured first fault diagnosis result.

[0037] It should be explained that the first fault diagnosis result includes the real-time operating parameters, fault codes, historical fault records, and sensor feedback data of each electronic control unit. These data are retrieved by the electronic control unit according to the acquisition instructions sent by the diagnostic equipment, and then encapsulated and transmitted back in accordance with the format of the corresponding network diagnostic protocol. The real-time operating parameters include the specific working indicators of different electronic control units, such as engine speed, fuel injection quantity, and shift signal parameters. The fault codes are standardized codes generated by the electronic control unit when it detects an abnormal state. The historical fault records are the retention of fault information that has occurred in the unit before. The sensor feedback data are the raw monitoring data collected by various vehicle sensors and transmitted to the electronic control unit.

[0038] The first fault diagnosis result is a structured diagnostic conclusion generated by the diagnostic equipment after analyzing the pre-processed first fault data. Specifically, it includes the specific location information of k electronic control units to be diagnosed, the fault type corresponding to each unit, the severity level of the fault, and the correlation between faults. It also covers the explanation of key data deviations related to the fault, such as the specific range of operating parameters exceeding the normal threshold, as well as the fault cause analysis and preliminary fault troubleshooting suggestions derived from the fault characteristic information.

[0039] The initial fault diagnosis results can be presented to the target user in the form of structured text reports, visual chart interfaces, or concise voice broadcasts. The structured text reports can clearly list the names of k electronic control units, their corresponding fault types, fault severity, fault cause analysis, and preliminary troubleshooting suggestions. The visual chart interface can intuitively present the deviation of each electronic control unit's operating parameters from the standard thresholds through bar charts, line charts, etc., and can also use color indicators to distinguish between normal and fault states. The voice broadcast format is suitable for scenarios where it is inconvenient for users to view the screen, converting the core diagnostic conclusions into easy-to-understand voice information. Different display formats can be flexibly switched according to the user's actual usage needs, ensuring that the user can quickly and accurately obtain the key content of the fault diagnosis.

[0040] As can be seen, the process first acquires the target user's voice description of the target vehicle, then determines the vehicle's characteristic information and fault characteristic information based on this voice description. Next, based on the fault characteristic information, it identifies k electronic control units (ECUs) that require fault diagnosis. Subsequently, it combines the vehicle characteristic information and the k ECUs to determine n network diagnostic protocols. Then, based on the n network diagnostic protocols, it obtains the first fault data corresponding to the k ECUs. Finally, it performs fault diagnosis on the k ECUs based on the first fault data to obtain the first fault diagnosis result. Using the user's voice description as the starting point for diagnosis can fully utilize the fault-related experience and perception information accumulated by the user during vehicle use, effectively reducing the initial reliance on professional equipment and personnel for fault diagnosis, and improving the convenience and universality of the diagnostic process. By extracting vehicle characteristic information and fault characteristic information from the voice description information, it can provide a basis for subsequent diagnosis. By clearly defining the scope of the diagnostic work, blind troubleshooting is avoided. Identifying k electronic control units (ECUs) to be diagnosed based on fault characteristic information allows for precise pinpointing of potentially problematic core components, reducing diagnostic operations on unrelated ECUs and significantly improving diagnostic efficiency. Furthermore, combining vehicle characteristic information and the k ECUs to determine n compatible network diagnostic protocols ensures the compatibility and accuracy of subsequent fault data collection, avoiding data acquisition failures or distortions due to protocol incompatibility. The initial fault data obtained based on these n compatible network diagnostic protocols possesses higher reliability and specificity. Fault diagnosis work based on this foundation effectively improves the accuracy of diagnostic results, helping repair personnel quickly locate the root cause of the fault and develop efficient and reasonable repair plans. This also provides reliable and efficient solutions for vehicle fault diagnosis in different scenarios, enhancing the efficiency of vehicle fault diagnosis.

[0041] Please see Figure 3 , Figure 3 This application provides a flowchart for determining n network diagnostic protocols, including but not limited to the following steps: S301: Based on the vehicle feature information, determine m network diagnostic protocols that are compatible with the target vehicle.

[0042] In this embodiment, m is an integer greater than n. First, it can be determined whether a network diagnostic protocol matching the vehicle's characteristic information exists in the local network diagnostic protocol database of the diagnostic device. The diagnostic device is a dedicated device used to perform diagnostic operations on the target vehicle. Its local database pre-stores a large amount of network diagnostic protocol data corresponding to common vehicle models. Then, a matching judgment is performed. If a protocol matching the target vehicle's characteristic information exists in the local database, all matching protocols are directly filtered from the local database, forming a set of m network diagnostic protocols. If no matching protocol exists in the local database, it indicates that the target vehicle may be a relatively rare model or equipped with a new electronic control system. In this case, the search is turned to the cloud server. The cloud server stores more comprehensive and richer network diagnostic protocol data, covering protocol types not included in the local database. By accurately matching the vehicle's characteristic information in the cloud server, m network diagnostic protocols suitable for the target vehicle can ultimately be selected.

[0043] For example, if the target vehicle's characteristic information is a plug-in hybrid compact sedan of a certain brand, with a plug-in hybrid powertrain and a flagship configuration, after obtaining this vehicle characteristic information, the diagnostic equipment will retrieve the protocol data stored in the local network diagnostic protocol database and filter out the protocols that match the brand and model. These include network diagnostic protocols applicable to the engine control unit, transmission control unit, battery management system, and body control module. These four filtered network diagnostic protocols are the m network diagnostic protocols that are compatible with the target vehicle.

[0044] S302: Determine the matching status of each of the m network diagnostic protocols with the k electronic control units to obtain m matching statuses.

[0045] In this embodiment, the matching status includes matching and non-matching, and each network diagnostic protocol corresponds to a matching status.

[0046] For each of the m network diagnostic protocols, a corresponding response command is generated based on the instruction format and communication specifications of each protocol. Each response command is sent to the k electronic control units (ECUs) of the target vehicle to be diagnosed. The response status of the k ECUs corresponding to each protocol is received and statistically analyzed. The response status is divided into two types: response and no response. Then, the k response statuses corresponding to each protocol are judged as a whole. If all the response statuses of the k ECUs corresponding to a certain protocol are no response, it is determined that the protocol is mismatched with the k ECUs. If at least one of the response statuses of the k ECUs corresponding to a certain protocol is a response, it is determined that the protocol is matched with the k ECUs. The verification of all m network diagnostic protocols is completed according to this judgment rule, and finally, m matching statuses corresponding one-to-one with the m network diagnostic protocols are obtained.

[0047] S303: Based on the m matching states, determine the network diagnostic protocol that matches the k electronic control units among the m network diagnostic protocols to obtain the n network diagnostic protocols.

[0048] In this implementation, the matching status of each of the m network diagnostic protocols needs to be determined first. Then, based on the matching status, all network diagnostic protocols that are determined to be matched are filtered out, while those that are determined to be mismatched are removed. Since some of the m network diagnostic protocols before filtering cannot establish effective communication with the k electronic control units, the number n of matching network diagnostic protocols obtained after filtering will be less than the initial m. Finally, the n network diagnostic protocols obtained by filtering and integration can both adapt to the hardware environment of the target vehicle and achieve effective communication with the k electronic control units to be diagnosed.

[0049] As can be seen, the process first determines m network diagnostic protocols compatible with the target vehicle based on vehicle feature information. Then, it determines the matching status of each of the m network diagnostic protocols with k electronic control units (ECUs) and obtains m matching statuses. Finally, based on the m matching statuses, it filters out n network diagnostic protocols that match the k ECUs. By initially filtering out m compatible protocols based on vehicle feature information, the selection range of network diagnostic protocols can be quickly narrowed, avoiding blindly filtering from a massive number of protocols and improving the overall efficiency of protocol filtering. At the same time, setting m to an integer greater than n reserves sufficient candidate space for subsequent precise filtering. By verifying the matching status of each protocol with the k ECUs one by one, protocols that are only compatible with the vehicle but cannot establish effective communication with the ECU to be diagnosed can be effectively eliminated, ensuring that the final n protocols have both vehicle compatibility and unit communication compatibility. Finally, the n protocols obtained based on the matching status provide a stable and reliable communication guarantee for obtaining the first fault data of the k ECUs, avoiding data acquisition failure or data distortion caused by protocol mismatch, reducing communication and time costs in the fault diagnosis process, and improving the overall efficiency and accuracy of vehicle fault diagnosis.

[0050] Please see Figure 4 , Figure 4 This application provides a flowchart for determining the matching status of a network diagnostic protocol, including but not limited to the following steps: S401: After sending response commands to the k electronic control units based on the first network diagnostic protocol, obtain the response status corresponding to the k electronic control units to obtain k response statuses.

[0051] In this embodiment, the response status includes responsive and non-responsive, and the first network diagnostic protocol is any one of the m network diagnostic protocols.

[0052] It should be explained that, since the first network diagnostic protocol is any one of the m network diagnostic protocols, the method for determining the matching status between each of the m network diagnostic protocols and the k electronic control units is the same as the method for determining the matching status between the first network diagnostic protocol and the k electronic control units. In this embodiment, the method for determining the matching status between the first network diagnostic protocol and the k electronic control units will be used as an example for explanation.

[0053] For the first network diagnostic protocol, corresponding response commands are generated according to the instruction format and communication specifications of the first network diagnostic protocol. The generated response commands are sent to the k electronic control units to be diagnosed in the target vehicle. After the sending operation is completed, the signal status fed back by these k electronic control units is received and recorded in real time. These statuses are divided into two types: response and no response. A response indicates that the corresponding electronic control unit can recognize the instruction format of the network diagnostic protocol and successfully feed back relevant data. No response indicates that the corresponding electronic control unit cannot recognize the instruction format of the first network diagnostic protocol or has a communication failure and has failed to feed back data. Finally, the feedback statuses of all electronic control units are summarized to form k response statuses that correspond one-to-one with the k electronic control units.

[0054] S402: If all k response states are no response, then it is determined that the first network diagnostic protocol is incompatible with the k electronic control units.

[0055] In this embodiment, if a response command is sent to k electronic control units (ECUs) to be diagnosed based on the first network diagnostic protocol, and none of the ECUs respond with any signal, it indicates that the instruction format communication specification of the network diagnostic protocol cannot be recognized or supported by any of the k ECUs. The ECUs cannot complete data retrieval or signal feedback according to the instructions of the protocol, and the two sides cannot establish an effective communication connection. This means that the protocol cannot meet the requirements for fault data collection from the k ECUs. Therefore, based on such communication interaction results, it can be directly determined that the first network diagnostic protocol is incompatible with the k ECUs.

[0056] S403: If at least one of the k response states is a response, then the first network diagnostic protocol is determined to be compatible with the k electronic control units.

[0057] In this embodiment, after a response command is sent to k electronic control units to be diagnosed based on the first network diagnostic protocol, as long as any one of the k electronic control units can recognize the command format and communication specifications of the protocol and thus feed back a valid signal to form a responsive state, it indicates that the network diagnostic protocol has the ability to establish a valid communication connection with some of the k electronic control units and can meet the basic requirements for fault data collection of these electronic control units. It is not necessary for the protocol to communicate with all electronic control units. Therefore, based on the existence of at least one responsive feedback result, it can be determined that the first network diagnostic protocol matches the k electronic control units.

[0058] It can be seen that the method of sending response commands to k electronic control units based on any network diagnostic protocol, obtaining the corresponding k response statuses, and then determining whether the protocol matches the k electronic control units based on whether all response statuses are non-response or at least one response is present has significant practical value. This method, through simple and clear communication interaction verification logic, can quickly and accurately complete the compatibility determination between the protocol and the electronic control units without the need for complex testing procedures or professional manual intervention, effectively reducing the operational difficulty and time cost of protocol screening. At the same time, using the existence of a valid response as the core of the judgment, it can accurately screen out protocols that have the ability to establish communication with the k electronic control units.

[0059] Please see Figure 5 , Figure 5 This application provides a flowchart for determining m network diagnostic protocols, including but not limited to the following steps: S501: Determine whether a network diagnostic protocol matching the vehicle feature information exists in the local network diagnostic protocol database of the diagnostic equipment.

[0060] In this embodiment, the diagnostic device is used to perform diagnostic operations on the target vehicle. First, core characteristic parameters such as the target vehicle's brand, model, production year, powertrain type, configuration, and version are extracted. Then, these parameters are used as search criteria for a comprehensive comparison in the network diagnostic protocol database stored locally on the diagnostic device. This database pre-includes network diagnostic protocol information for a large number of common vehicle models and also stores the vehicle characteristic parameter ranges adapted to each protocol. During the comparison process, the system verifies whether the target vehicle's characteristic parameters match the adaptation parameters associated with each protocol in the database, thereby determining whether a network diagnostic protocol directly adapts to the target vehicle exists.

[0061] S502: If so, then determine the m network diagnostic protocols that match the vehicle feature information from the local network diagnostic protocol database.

[0062] In this embodiment, if a network diagnostic protocol matching the vehicle characteristic information exists in the local network diagnostic protocol database of the diagnostic device, then all network diagnostic protocols that completely match or are compatible with the core characteristic parameters such as brand, model, production year, power type, and configuration version of the target vehicle are selected from the local network diagnostic protocol database of the diagnostic device, thereby obtaining the m network diagnostic protocols matching the vehicle characteristic information. Relying on the local network diagnostic protocol database of the diagnostic device to complete the protocol selection eliminates the need to call cloud server resources, effectively shortening the protocol acquisition time and improving the efficiency of the overall diagnostic process.

[0063] S503: If not, then determine the m network diagnostic protocols that match the vehicle feature information from the cloud server.

[0064] In this embodiment, if no network diagnostic protocol matching the target vehicle's characteristic information exists in the local network diagnostic protocol database of the diagnostic device, then m network diagnostic protocols matching the vehicle's characteristic information are determined from the cloud server. First, a protocol acquisition request is generated based on the core characteristic information of the target vehicle, such as brand, model, production year, power type, and configuration version. Then, the request is sent to the cloud server. This request instructs the cloud server to return a list of candidate protocols related to the target vehicle's characteristic information to the diagnostic device. After the diagnostic device receives the list of candidate protocols returned by the cloud server, it filters all protocols in the list one by one, extracts protocols that completely match or are compatible with the target vehicle's characteristic information, and integrates them to form a set of m network diagnostic protocols. At the same time, these m network diagnostic protocols are stored in the local network diagnostic protocol database.

[0065] For example, based on the vehicle feature information, a protocol acquisition request for the target vehicle is sent to the cloud server. The protocol acquisition request is used to request the cloud server to send a list of candidate protocols related to the vehicle feature information to the diagnostic device. Specifically, the diagnostic device first extracts core feature information such as the brand, model, production year, power type, and configuration version of the target vehicle, and then encapsulates this information into a standardized protocol acquisition request, which is sent to the cloud server through the communication network. The core purpose of this protocol acquisition request is to instruct the cloud server to filter out protocol content related to the target vehicle attributes from the massive network diagnostic protocol resources stored in the cloud based on the vehicle feature information it carries, and then generate a corresponding list of candidate protocols and feed it back to the diagnostic device.

[0066] For example, after receiving the candidate protocol list from the cloud server, the diagnostic device filters out m network diagnostic protocols that match the vehicle feature information from the candidate protocol list and stores the m network diagnostic protocols in the local network diagnostic protocol database. Specifically, after receiving the candidate protocol list returned by the cloud, the diagnostic device compares the adaptable vehicle parameters of each protocol in the list with the feature information of the target vehicle one by one according to the preset matching rules, filters out all protocols that are completely matched or compatible, and integrates them to form a network diagnostic protocol set of m. At the same time, in order to enrich the protocol reserves of the local database and improve the efficiency of subsequent diagnosis of similar models, the diagnostic device will synchronously store these m filtered network diagnostic protocols in the local network diagnostic protocol database, thereby realizing the localized accumulation of network diagnostic protocols in the diagnostic device.

[0067] It should be noted that in this embodiment, please refer to Figure 6 ,Figure 6 This application provides an architecture block diagram for determining a second fault diagnosis result. First, the first fault diagnosis result is displayed and user satisfaction is collected. Branching is performed based on satisfaction assessment. If the satisfaction level is greater than or equal to a threshold, the process ends. If the satisfaction level is less than the threshold, the first diagnosis result is displayed first, then an inquiry command is sent to guide the user to supplement p electronic control units (ECUs). Next, the second fault data for the corresponding p units is obtained. After completing the secondary diagnosis, the second fault diagnosis result is displayed, and the process ends. Specifically, after obtaining the target user's satisfaction with the first fault diagnosis result, if the satisfaction level is lower than a preset satisfaction threshold, it indicates that the initial diagnosis did not fully address the user's needs. In this case, an inquiry command can be sent to the user based on the k diagnosed ECUs, guiding the user to supplement p ECUs that need to be diagnosed in addition to the k ECUs. Then, combining vehicle feature information and the newly added p ECUs, q compatible network diagnostic protocols are determined. Based on the q network diagnostic protocols, the second fault data corresponding to the p ECUs is obtained. Finally, fault diagnosis is performed on the p ECUs based on the second fault data to obtain the second fault diagnosis result.

[0068] It can be seen that by taking user satisfaction as the guide and guiding users to supplement the electronic control units that need to be diagnosed, the coverage of fault diagnosis is expanded, avoiding the omission of electronic control units that need to be diagnosed in the initial diagnosis. At the same time, by combining the vehicle characteristics to match the network diagnostic protocol, the accuracy of fault data collection of newly added electronic control units is ensured. Finally, a more comprehensive diagnostic result is obtained through secondary diagnosis, which not only improves the accuracy and completeness of fault diagnosis, but also better meets the actual needs of users and enhances users' recognition of diagnostic services.

[0069] In summary, implementing the embodiments of the present invention has the following beneficial effects: As can be seen, the vehicle fault diagnosis method described in this embodiment of the invention first obtains voice description information of the target user regarding the target vehicle, then determines vehicle feature information and fault feature information corresponding to the target vehicle based on the voice description information, then determines the k electronic control units (ECUs) in the target vehicle that require fault diagnosis based on the fault feature information, then determines n network diagnostic protocols based on the vehicle feature information and the k ECUs, then obtains first fault data corresponding to the k ECUs based on the n network diagnostic protocols, and finally performs fault diagnosis on the k ECUs based on the first fault data to obtain a first fault diagnosis result. Using the embodiments of this application improves the efficiency of vehicle fault diagnosis.

[0070] Please see Figure 7 , Figure 7This is a schematic diagram of the structure of a vehicle fault diagnosis device provided in an embodiment of this application. The vehicle fault diagnosis device 700 includes: an acquisition unit 701 and a processing unit 702. The acquisition unit 701 is used to acquire the voice description information of the target user for the target vehicle; The processing unit 702 is used to determine the vehicle feature information and fault feature information corresponding to the target vehicle based on the voice description information; Based on the fault characteristic information, the k electronic control units in the target vehicle that require fault diagnosis are identified; k is an integer greater than 1. Based on the vehicle characteristic information and the k electronic control units, n network diagnostic protocols are determined; n is an integer greater than 1. The first fault data corresponding to the k electronic control units is obtained based on the n network diagnostic protocols; Based on the first fault data, fault diagnosis is performed on the k electronic control units to obtain the first fault diagnosis result.

[0071] In some possible implementations, in determining n network diagnostic protocols based on the vehicle characteristic information and the k electronic control units, the processing unit 702 is specifically used for: Based on the vehicle feature information, m network diagnostic protocols adapted to the target vehicle are determined; m is an integer greater than n. Determine the matching status of each of the m network diagnostic protocols with the k electronic control units to obtain m matching statuses; the matching status includes matching and non-matching, and each network diagnostic protocol corresponds to one matching status. Based on the m matching states, determine the network diagnostic protocol that matches the k electronic control units among the m network diagnostic protocols to obtain the n network diagnostic protocols.

[0072] In some possible implementations, in determining the matching status of each of the m network diagnostic protocols with the k electronic control units to obtain m matching statuses, the processing unit 702 is specifically used for: After sending response commands to the k electronic control units based on the first network diagnostic protocol, the response status corresponding to the k electronic control units is obtained, resulting in k response statuses; the response status includes response and no response, and the first network diagnostic protocol is any one of the m network diagnostic protocols; If all k response states are no response, then it is determined that the first network diagnostic protocol is incompatible with the k electronic control units; If at least one of the k response states is a response, then the first network diagnostic protocol is determined to be compatible with the k electronic control units.

[0073] In some possible implementations, in determining the m network diagnostic protocols compatible with the target vehicle based on the vehicle feature information, the processing unit 702 is specifically used for: The diagnostic device determines whether a network diagnostic protocol matching the vehicle's characteristic information exists in its local network diagnostic protocol database; the diagnostic device is used to perform diagnostic operations on the target vehicle. If so, then determine the m network diagnostic protocols that match the vehicle feature information from the local network diagnostic protocol database; If not, then determine the m network diagnostic protocols that match the vehicle feature information from the cloud server.

[0074] In some possible implementations, in determining the m network diagnostic protocols that match the vehicle feature information from the cloud server, the processing unit 702 is specifically used for: Based on the vehicle feature information, a protocol acquisition request for the target vehicle is sent to the cloud server; the protocol acquisition request is used to request the cloud server to send a list of candidate protocols related to the vehicle feature information to the diagnostic device. After receiving the candidate protocol list from the cloud server, the system selects m network diagnostic protocols that match the vehicle feature information from the candidate protocol list and stores the m network diagnostic protocols in the local network diagnostic protocol database.

[0075] In some possible implementations, the processing unit 702 is further specifically used for: Obtain the target user's satisfaction with the first fault diagnosis result; If the satisfaction level is less than the satisfaction threshold, an inquiry instruction is sent to the target user based on the k electronic control units; the inquiry instruction is used by the target user to add p electronic control units other than the k electronic control units that need to be diagnosed; p is an integer; Based on the vehicle characteristic information and the p electronic control units, q network diagnostic protocols are determined; q is an integer greater than 1. The second fault data corresponding to the p electronic control units is obtained based on the q network diagnostic protocols; Based on the second fault data, fault diagnosis is performed on the p electronic control units to obtain the second fault diagnosis result.

[0076] Please see Figure 8 , Figure 8This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. For example... Figure 8 As shown, the electronic device 800 includes a transceiver 801, a processor 802, and a memory 803. These are connected via a bus 804. The memory 803 stores computer programs and data, and the transceiver 801 can transmit data stored in the memory 803 to the processor 802. The program includes instructions for performing the following steps: Obtain the target user's voice description information for the target vehicle; Based on the voice description information, determine the vehicle characteristic information and fault characteristic information corresponding to the target vehicle; Based on the fault characteristic information, the k electronic control units in the target vehicle that require fault diagnosis are identified; k is an integer greater than 1. Based on the vehicle characteristic information and the k electronic control units, n network diagnostic protocols are determined; n is an integer greater than 1. The first fault data corresponding to the k electronic control units is obtained based on the n network diagnostic protocols; Based on the first fault data, fault diagnosis is performed on the k electronic control units to obtain the first fault diagnosis result.

[0077] In some possible implementations, the above procedure includes instructions for performing the following steps in determining n network diagnostic protocols based on the vehicle characteristic information and the k electronic control units: Based on the vehicle feature information, m network diagnostic protocols adapted to the target vehicle are determined; m is an integer greater than n. Determine the matching status of each of the m network diagnostic protocols with the k electronic control units to obtain m matching statuses; the matching status includes matching and non-matching, and each network diagnostic protocol corresponds to one matching status. Based on the m matching states, determine the network diagnostic protocol that matches the k electronic control units among the m network diagnostic protocols to obtain the n network diagnostic protocols.

[0078] In some possible implementations, in determining the matching status of each of the m network diagnostic protocols with the k electronic control units to obtain m matching statuses, the above procedure includes instructions for performing the following steps: After sending response commands to the k electronic control units based on the first network diagnostic protocol, the response status corresponding to the k electronic control units is obtained, resulting in k response statuses; the response status includes response and no response, and the first network diagnostic protocol is any one of the m network diagnostic protocols; If all k response states are no response, then it is determined that the first network diagnostic protocol is incompatible with the k electronic control units; If at least one of the k response states is a response, then the first network diagnostic protocol is determined to be compatible with the k electronic control units.

[0079] In some possible implementations, regarding the determination of m network diagnostic protocols compatible with the target vehicle based on the vehicle characteristic information, the above procedure includes instructions for performing the following steps: The diagnostic device determines whether a network diagnostic protocol matching the vehicle's characteristic information exists in its local network diagnostic protocol database; the diagnostic device is used to perform diagnostic operations on the target vehicle. If so, then determine the m network diagnostic protocols that match the vehicle feature information from the local network diagnostic protocol database; If not, then determine the m network diagnostic protocols that match the vehicle feature information from the cloud server.

[0080] In some possible implementations, the above procedure includes instructions for performing the following steps in determining the m network diagnostic protocols that match the vehicle feature information from a cloud server: Based on the vehicle feature information, a protocol acquisition request for the target vehicle is sent to the cloud server; the protocol acquisition request is used to request the cloud server to send a list of candidate protocols related to the vehicle feature information to the diagnostic device. After receiving the candidate protocol list from the cloud server, the system selects m network diagnostic protocols that match the vehicle feature information from the candidate protocol list and stores the m network diagnostic protocols in the local network diagnostic protocol database.

[0081] In some possible implementations, the above procedure includes instructions for performing the following steps: Obtain the target user's satisfaction with the first fault diagnosis result; If the satisfaction level is less than the satisfaction threshold, an inquiry instruction is sent to the target user based on the k electronic control units; the inquiry instruction is used by the target user to add p electronic control units other than the k electronic control units that need to be diagnosed; p is an integer; Based on the vehicle characteristic information and the p electronic control units, q network diagnostic protocols are determined; q is an integer greater than 1. The second fault data corresponding to the p electronic control units is obtained based on the q network diagnostic protocols; Based on the second fault data, fault diagnosis is performed on the p electronic control units to obtain the second fault diagnosis result.

[0082] It should be understood that the electronic devices mentioned in this application may include smartphones (such as Android phones, iOS phones, Windows Phones, etc.), tablets, PDAs, laptops, mobile internet devices (MIDs) or wearable devices, servers, edge computing nodes, etc. The above-mentioned electronic devices are merely examples and not exhaustive, and include, but are not limited to, the electronic devices described above.

[0083] This application also provides a computer-readable storage medium storing a computer program that is executed by a processor to implement some or all of the steps of any of the methods described in the above method embodiments.

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

[0085] It should be noted that, for the sake of simplicity, the aforementioned methods 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. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are optional, and the actions and modules involved are not necessarily essential to this application.

[0086] In the above embodiments, the descriptions of each embodiment have their own emphasis. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0087] In the several embodiments provided in this application, it should be understood that the disclosed apparatus can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between devices or units may be electrical or other forms.

[0088] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment, depending on actual needs.

[0089] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software program module.

[0090] If the integrated unit is implemented as a software program module and sold or used as an independent product, it can be stored in a computer-readable storage device (CMD). Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a memory and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned memory includes various media capable of storing program code, such as USB flash drives, read-only memory (ROM), random access memory (RAM), portable hard drives, magnetic disks, or optical disks.

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

[0092] The embodiments of this application have been described in detail above. Specific examples have been used to illustrate the principles and implementation methods of this application. The above description of the embodiments is only for the purpose of helping to understand the method and core ideas of this application. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this application. Therefore, the content of this specification should not be construed as a limitation of this application.

Claims

1. A vehicle fault diagnosis method, characterized in that, include: Obtain the target user's voice description information for the target vehicle; Based on the voice description information, determine the vehicle characteristic information and fault characteristic information corresponding to the target vehicle; Based on the fault characteristic information, k electronic control units in the target vehicle that require fault diagnosis are identified; k is an integer greater than 1. Based on the vehicle characteristic information and the k electronic control units, n network diagnostic protocols are determined; n is an integer greater than 1. The first fault data corresponding to the k electronic control units is obtained based on the n network diagnostic protocols; Based on the first fault data, fault diagnosis is performed on the k electronic control units to obtain the first fault diagnosis result.

2. The method as described in claim 1, characterized in that, The determination of n network diagnostic protocols based on the vehicle feature information and the k electronic control units includes: Based on the vehicle feature information, m network diagnostic protocols adapted to the target vehicle are determined; m is an integer greater than n. Determine the matching status of each of the m network diagnostic protocols with the k electronic control units to obtain m matching statuses; the matching status includes matching and non-matching, and each network diagnostic protocol corresponds to one matching status. Based on the m matching states, determine the network diagnostic protocol that matches the k electronic control units among the m network diagnostic protocols to obtain the n network diagnostic protocols.

3. The method as described in claim 2, characterized in that, The process of determining the matching status between each of the m network diagnostic protocols and the k electronic control units yields m matching statuses, including: After sending response commands to the k electronic control units based on the first network diagnostic protocol, the response status corresponding to the k electronic control units is obtained, resulting in k response statuses; the response status includes response and no response, and the first network diagnostic protocol is any one of the m network diagnostic protocols; If all k response states are no response, then it is determined that the first network diagnostic protocol is incompatible with the k electronic control units; If at least one of the k response states is a response, then the first network diagnostic protocol is determined to be compatible with the k electronic control units.

4. The method as described in claim 3, characterized in that, The step of determining m network diagnostic protocols compatible with the target vehicle based on the vehicle feature information includes: The diagnostic device determines whether a network diagnostic protocol matching the vehicle's characteristic information exists in its local network diagnostic protocol database; the diagnostic device is used to perform diagnostic operations on the target vehicle. If so, then determine the m network diagnostic protocols that match the vehicle feature information from the local network diagnostic protocol database; If not, then determine the m network diagnostic protocols that match the vehicle feature information from the cloud server.

5. The method as described in claim 4, characterized in that, The step of determining the m network diagnostic protocols that match the vehicle feature information from the cloud server includes: Based on the vehicle feature information, a protocol acquisition request for the target vehicle is sent to the cloud server; the protocol acquisition request is used to request the cloud server to send a list of candidate protocols related to the vehicle feature information to the diagnostic device. After receiving the candidate protocol list from the cloud server, the system selects m network diagnostic protocols that match the vehicle feature information from the candidate protocol list and stores the m network diagnostic protocols in the local network diagnostic protocol database.

6. The method according to any one of claims 1-5, characterized in that, The method further includes: Obtain the target user's satisfaction with the first fault diagnosis result; If the satisfaction level is less than the satisfaction threshold, an inquiry instruction is sent to the target user based on the k electronic control units; the inquiry instruction is used by the target user to add p electronic control units other than the k electronic control units that need to be diagnosed; p is an integer; Based on the vehicle characteristic information and the p electronic control units, q network diagnostic protocols are determined; q is an integer greater than 1. The second fault data corresponding to the p electronic control units is obtained based on the q network diagnostic protocols; Based on the second fault data, fault diagnosis is performed on the p electronic control units to obtain the second fault diagnosis result.

7. A vehicle fault diagnosis device, characterized in that, The device includes: an acquisition unit and a processing unit; The acquisition unit is used to acquire the voice description information of the target user for the target vehicle; The processing unit is used to determine the vehicle feature information and fault feature information corresponding to the target vehicle based on the voice description information; Based on the fault characteristic information, k electronic control units in the target vehicle that require fault diagnosis are identified; k is an integer greater than 1. Based on the vehicle characteristic information and the k electronic control units, n network diagnostic protocols are determined; n is an integer greater than 1. The first fault data corresponding to the k electronic control units is obtained based on the n network diagnostic protocols; Based on the first fault data, fault diagnosis is performed on the k electronic control units to obtain the first fault diagnosis result.

8. An electronic device, characterized in that, The method includes 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 one or more programs include instructions for performing the steps of the method according to any one of claims 1-6.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that is executed by a processor to implement the method as described in any one of claims 1-6.

10. A computer program product, characterized in that, When the computer program product is run on a computer, it causes the computer to perform the method as described in any one of claims 1-6.

Images