Communication fault-tolerant method, system, medium and product of an automobile diagnostic device

Abstract

This invention relates to a communication fault-tolerant method, system, medium, and product for automotive diagnostic equipment. In this method, when the diagnostic equipment fails to communicate with the designated system of a target vehicle on its first attempt, it retrieves a configuration database of systems of the same brand and type. The database is then sorted hierarchically according to the protocol type, baud rate, and communication pins of each configuration item in the configuration set. The target configuration item with successful communication is located and verified to determine the current system identifier of the target vehicle. A communication connection is then established with the target vehicle, and diagnostic functions are executed. This invention solves the problem of communication failures caused by incorrect vehicle model selection or unsupported communication protocols, enabling the monitoring of automotive system faults and data stream data.

Description

Technical Field

[0001] This application belongs to the field of automotive diagnostic equipment, and particularly relates to a communication fault-tolerant method, system, medium and product for automotive diagnostic equipment. Background Technology

[0002] With rapid economic development, the automotive market is booming, and the number of cars is constantly increasing. To meet market demand, automakers are designing increasingly complex vehicles, and the types of engines and transmissions are becoming increasingly diverse. In the field of automotive fault detection, diagnosis, and repair, it has become particularly important for customers to use diagnostic equipment to monitor vehicle problems. This not only relates to the normal operation of the vehicle and maintenance efficiency but also affects the customer experience and the development of the automotive repair industry.

[0003] Traditionally, vehicle model selection primarily involves using OBD to read the VIN (Vehicle Identifier), followed by automatic VIN parsing by the diagnostic equipment to access the corresponding vehicle path. However, many vehicle models do not support OBD's broadcast method for reading the VIN. Furthermore, the communication mode for reading the VIN on diagnostic equipment often uses cost-effective chips that cannot support all communication protocols due to cost and data mode considerations during manufacturing. This can lead to communication failures during VIN reading, preventing the VIN from being retrieved. Additionally, insufficient engineer expertise and inadequate implementation of certain communication protocols can also cause communication problems between the diagnostic equipment and the vehicle, preventing VIN reading. Even if the VIN is read, if the vehicle model data is limited or outdated, vehicle model parsing may be difficult. In such cases, customers may manually select the vehicle model for diagnostics.

[0004] However, when customers select the wrong vehicle model, accessing the vehicle model system will fail. Furthermore, the diagnostic equipment has numerous issues with reading and parsing the VIN, such as not supporting certain vehicle model reading methods, the chip not supporting all communication protocols, incomplete communication protocols, and untimely updates to vehicle model data. These problems lead to a poor customer experience when using the diagnostic equipment, and may even cause customers to believe that the diagnostic product is faulty and not purchase it again. Summary of the Invention

[0005] This application provides a communication fault-tolerant method, system, medium, and product for automotive diagnostic equipment, used to solve communication failure problems caused by incorrect vehicle model selection or unsupported communication protocols. The method quickly and efficiently locates the target configuration item for successful communication by retrieving and sorting the configuration database of systems of the same brand and type, determining the current system identifier of the target vehicle, and then establishing a communication connection with the target vehicle to perform diagnostics.

[0006] In a first aspect, this application provides a communication fault-tolerant method for automotive diagnostic equipment, including: When the diagnostic device fails to communicate with the designated system of the target vehicle for the first time, it retrieves the configuration database of the same brand and type of system, and obtains a configuration set containing multiple configuration items, where each configuration item corresponds to a set of protocol type, baud rate, communication pin and unique system identifier. Based on the protocol type, baud rate, and communication pin of each configuration item in the configuration set, they are sequentially sorted according to a preset priority to obtain a hierarchical communication sequence; Based on the hierarchical communication sequence, connection requests are sent sequentially to the target vehicle, and all remaining configuration items under the corresponding level are skipped according to the level where the communication failed, so as to determine the target configuration item where the communication was successful. The corresponding entry command is sent to the target vehicle according to the target configuration item, and the returned data is matched based on the verification algorithm to determine the current system identifier of the target vehicle; A communication connection is established with the target vehicle based on the current system identifier, and corresponding diagnostic functions are performed.

[0007] In the above implementation, when the diagnostic device fails to communicate with the designated system of the target vehicle for the first time, the system retrieves the configuration database of the same brand and type of system, and sorts the configuration items in the configuration set according to their protocol type, baud rate and communication pins. The system then finds the target configuration item that has successfully communicated and verifies it, determines the current system identifier of the target vehicle, and establishes a communication connection with the target vehicle to perform diagnostic functions. This solves the communication failure problem caused by selecting the wrong vehicle model or not supporting the communication protocol, and enables the monitoring of vehicle system faults and data stream data.

[0008] In one implementation, after the step of determining the current system identifier of the target vehicle, the method further includes: A mapping relationship is established and stored between the current system identifier and the vehicle model route selected by the user, thus obtaining a historical mapping table; When a user selects the same vehicle model path to initiate a diagnostic, the corresponding system identifier is directly retrieved based on the historical mapping table to communicate with the target vehicle, skipping the hierarchical polling process.

[0009] In the above implementation, after determining the current system identifier of the target vehicle, a mapping relationship is established between the current system identifier and the vehicle model path selected by the user this time and stored. When the user selects the same vehicle model path again to initiate diagnosis, the corresponding system identifier can be directly retrieved to communicate with the target vehicle, skipping the hierarchical polling process, saving time and improving communication efficiency.

[0010] In one implementation, the diagnostic functions include basic diagnostic functions and extended functions, and prior to the step of determining the current system identifier of the target vehicle, the method further includes: If all configuration items in the configuration set communicate successfully but no corresponding system identifier is matched, the system identifier at the end of the hierarchical communication sequence will be used as the default model. When a communication connection is established based on the default model, the display and access to all extended functions are disabled, and only the basic diagnostic functions are enabled.

[0011] In the above implementation, when all configuration items in the configuration set communicate successfully but no corresponding system identifier is matched, the system identifier at the end of the hierarchical communication sequence is taken as the default model. When establishing a communication connection based on the default model, the display and call entry of all extended functions are blocked, and only the basic diagnostic functions are opened. This can ensure the normal communication of the engine system to a certain extent, realize basic diagnostic functions such as basic function version information, reading fault codes, and clearing fault codes, and at the same time avoid the vehicle safety problems caused by using extended functions such as action testing, special functions, and coding due to incomplete matching.

[0012] In one implementation, the matching logic of the verification algorithm includes: Extract the value of a specific byte from the returned data; The numerical value is compared with the preset mask value corresponding to the system identifier by bitwise operations, and whether the match is successful is determined based on whether the comparison results are consistent.

[0013] In the above implementation, when determining the current system identifier of the target vehicle, a verification algorithm is used to extract the value of a specific byte in the returned data and perform bitwise operations to compare it with the preset mask value corresponding to the system identifier. This can accurately determine whether the match is successful, thereby more accurately determining the current system identifier of the target vehicle and laying the foundation for establishing a communication connection with the target vehicle and performing diagnostic functions.

[0014] In one implementation, after obtaining the configuration set containing multiple configuration items, the method further includes: Obtain the vehicle model identification information of the target vehicle, wherein the vehicle model identification information includes at least one of the following: the model year field in the vehicle identification number (VIN), the engine displacement code, and the level characteristics of the idle pins of the OBD interface; Based on the vehicle identification information, protocol types or pin combinations that do not match obviously in the configuration set are removed to obtain a subset of configurations to be sorted; The configuration items in the unsorted configuration subset are sorted hierarchically according to their preset priorities to obtain a preliminary hierarchical communication sequence.

[0015] In the above implementation, obtaining the vehicle model identification information of the target vehicle can provide a basis for screening the configuration set; based on the vehicle model identification information, eliminating obviously mismatched protocol types or pin combinations can narrow the communication range, reduce unnecessary communication attempts, and improve communication efficiency; sorting the obtained subset of configurations to be sorted according to a preset priority to obtain a preliminary hierarchical communication sequence helps to communicate with the target vehicle in an orderly manner, quickly find the target configuration item that has successfully communicated, and thus more efficiently determine the current system identifier of the target vehicle.

[0016] In one implementation, each configuration item in the configuration database is associated with a successful matching weight value, the weight value being generated based on the historical successful matching count of the configuration item; the method further includes: Based on the initial hierarchical communication sequence, for different pin combination configuration items under the same protocol type and the same baud rate, the pins are rearranged from high to low according to the weight values ​​to obtain the optimized hierarchical communication sequence. After determining the current system identifier, the weight value corresponding to the target configuration item is incremented and updated according to the matching result.

[0017] In the above implementation, a matching success weight value is generated based on the historical number of successful matches of the configuration item. The configuration items with different pin combinations under the same protocol type and baud rate are rearranged in descending order of weight value to obtain an optimized hierarchical communication sequence, which improves the efficiency and accuracy of communication matching. After determining the current system identifier, the weight value corresponding to the target configuration item is updated incrementally, which makes the weight value more accurately reflect the matching success rate of the configuration item and further optimizes the hierarchical communication sequence.

[0018] In one embodiment, the method further includes: According to a preset cycle, the weight values ​​of each local configuration item and the corresponding vehicle identification information are uploaded to the cloud server to obtain local uploaded data; Receive the global weight value issued by the cloud server after aggregating and calculating the locally uploaded data from multiple diagnostic devices, and obtain the global weight value corresponding to each configuration item; The weight values ​​of the corresponding configuration items in the local configuration database are updated based on the global weight values ​​to obtain the optimized hierarchical communication sequence.

[0019] In the above implementation, the weight values ​​of each local configuration item and vehicle model identification information are uploaded to the cloud server. After aggregation and calculation, the global weight value is obtained and the local configuration database is updated. An optimized hierarchical communication sequence can be obtained. The accuracy and reliability of the configuration item weight values ​​are improved by using data from multiple diagnostic devices, thereby improving the efficiency and success rate of matching target configuration items in subsequent communication processes.

[0020] In a second aspect, embodiments of this application provide a communication fault-tolerant system for an automotive diagnostic device, comprising: one or more processors and a memory; the memory is coupled to one or more processors, the memory being used to store computer program code, the computer program code including computer instructions, and one or more processors invoking the computer instructions to cause the system to perform the method described in the first aspect and any possible implementation thereof.

[0021] Thirdly, embodiments of this application provide a computer-readable storage medium including instructions that, when executed on a system, cause the system to perform the method described in the first aspect and any possible implementation thereof.

[0022] Fourthly, embodiments of this application provide a computer program product that, when run on a system, causes the system to perform the method described in the first aspect and any possible implementation thereof.

[0023] One or more technical solutions provided in the embodiments of this application have at least the following technical effects or advantages: 1. This application provides a communication fault tolerance method for automotive diagnostic equipment. When the diagnostic equipment fails to communicate with the designated system of the target vehicle for the first time, it can determine the target configuration item that has successfully communicated by retrieving the configuration database of the same brand and type of system and sorting the communication in a hierarchical manner, thereby establishing a communication connection with the target vehicle and realizing the monitoring of fault codes and other data. 2. This application provides a communication fault tolerance method for automotive diagnostic equipment, which establishes and stores a mapping relationship between the vehicle model selected by the user and the corresponding system identifier that can communicate. The corresponding system identifier can be directly retrieved for communication in the next communication, saving time and improving efficiency. 3. This application provides a communication fault tolerance method for automotive diagnostic equipment. If all configuration items in the configuration set communicate successfully but no corresponding system identifier is matched, the system identifier at the end of the hierarchical communication sequence is used as the default model, the extended functions are blocked, and only the basic diagnostic functions are enabled to avoid automotive safety issues. Attached Figure Description

[0024] Figure 1 This is a flowchart illustrating a communication fault-tolerant method for an automotive diagnostic device according to an embodiment of this application.

[0025] Figure 2 This is another flowchart illustrating a communication fault-tolerant method for an automotive diagnostic device in an embodiment of this application.

[0026] Figure 3 This is a schematic diagram of the physical device structure of a communication fault-tolerant method for automotive diagnostic equipment provided in an embodiment of this application. Detailed Implementation

[0027] The terminology used in the following embodiments of this application is for the purpose of describing particular embodiments only and is not intended to be limiting of this application. As used in the specification and appended claims of this application, the singular expressions “a,” “an,” “the,” “the,” “the,” and “this” are intended to include the plural expressions as well, unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used in this application refers to any or all possible combinations including one or more of the listed items.

[0028] Hereinafter, the terms "first" and "second" are used for descriptive purposes only and should not be construed as implying or suggesting relative importance or implicitly indicating the number of indicated technical features. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature, and in the description of the embodiments of this application, unless otherwise stated, "multiple" means two or more. In the field of automotive fault detection, diagnosis and repair, stable communication between diagnostic equipment and vehicle electronic control units (ECUs) is a prerequisite for obtaining fault information.

[0029] In related technologies, diagnostic equipment typically relies on reading the vehicle identification number (VIN) to automatically match communication protocols and pin definitions. However, due to limitations such as some older vehicle models not supporting OBD broadcast reading, incomplete hardware chip protocol support, or lagging vehicle model database updates, VIN reading failures or parsing errors frequently occur. When users manually select the wrong vehicle model, causing communication failure, traditional equipment often lacks an effective error correction mechanism or simply reports an error and exits, leading users to misjudge it as a product quality issue, severely impacting repair efficiency and user experience.

[0030] This application is primarily applied to scenarios where automotive diagnostic equipment establishes a communication connection with a vehicle's ECU, particularly suitable for edge cases where the user manually selects the wrong vehicle model, the VIN code cannot be parsed, or the vehicle's communication protocol is unknown. In these application scenarios, the core challenge lies in how to quickly locate the correct communication parameters from massive amounts of configuration data without user intervention, and continuously improve communication efficiency in subsequent use. To address the aforementioned technical problems, this application provides a communication fault-tolerant method, system, medium, and product for automotive diagnostic equipment. An embodiment is described below in conjunction with… Figure 1 The following describes a communication fault-tolerant method for an automotive diagnostic device according to an embodiment of this application: Please see Figure 1 This is a flowchart illustrating a communication fault-tolerant method for an automotive diagnostic device according to an embodiment of this application.

[0031] S101. When the diagnostic device fails to communicate with the designated system of the target vehicle for the first time, the configuration database of the same brand and type of system is retrieved to obtain a configuration set containing multiple configuration items.

[0032] Each configuration item corresponds to a set of protocol types, baud rates, communication pins, and a unique system identifier.

[0033] Specifically, the configuration database can be stored locally on the diagnostic device or a remote database connected via a network. Protocol types can include standard CAN, EXCAN, KWP, IOS, VPW, PWM, negative logic, etc., and these protocols may have different applications in different automotive systems. Baud rates can be 500K, 250K, 10400, 9600, etc., with different baud rates determining the data transmission speed. Communication pins are the physical interfaces for communication between the diagnostic device and the vehicle. Common communication pin combinations include pins 6 and 14 (for CAN bus communication), pins 7 and 15 (for K-line / L-line communication), and pin 2 (for VPW / PWM communication) in the OBD-II interface. The system identifier is used to uniquely identify a vehicle system. For example, engine systems under the same brand may have multiple system identifiers depending on the production year, displacement, and supplier.

[0034] It should be noted that "same brand, same type of system" refers to the collection of all vehicle systems of the same type as the specified system under the target vehicle's brand. This same type of system includes, but is not limited to, engine systems, transmission systems, airbag systems, door control systems, body control systems, and ABS anti-lock braking systems. For the same type of system across different vehicle brands, separate configuration databases are established in the diagnostic equipment to avoid mismatches caused by differences in protocol specifications between different brands.

[0035] In some optional implementations, the criteria for determining initial communication failure include: after the diagnostic device sends a connection request to the target vehicle according to the vehicle model path selected by the user, it does not receive returned data within a preset timeout period (e.g., 3 seconds), or the checksum of the returned data does not conform to the protocol specification. When the initial communication is determined to have failed, it indicates that there is a discrepancy between the default system configuration corresponding to the vehicle model path selected by the user and the actual system configuration of the target vehicle, thus triggering the fault tolerance process of this embodiment.

[0036] Since the configuration database may not be updated in time due to the iteration of the diagnostic device version, the diagnostic device first verifies the database version number before retrieving the configuration database. If the version number is lower than the latest version supported by the current device, an incremental update is triggered first, and then the subsequent retrieval actions are performed to ensure the completeness of the configuration items.

[0037] S102. Based on the protocol type, baud rate and communication pin of each configuration item in the configuration set, sort them in order according to the preset priority to obtain a hierarchical communication sequence.

[0038] Specifically, the preset priority can be set according to the communication time of the protocols. For example, protocols with shorter communication times are ranked first, such as the CAN protocol, which typically has a shorter communication time, and protocols with longer communication times, such as the negative logic protocol, are ranked later. In one optional implementation, the priority order of protocol types is: CAN protocol > EXCAN protocol > KWP protocol > VPW protocol > ISO protocol > negative logic protocol > DDL1 protocol.

[0039] Furthermore, baud rates can also be sorted according to communication time. For example, the 500K baud rate under the CAN protocol has a faster communication speed and can be ranked before the 250K baud rate. The 10400 baud rate under the KWP protocol can be ranked before the 9600 baud rate. Communication pins can also be sorted according to factors such as communication stability and historical usage frequency. For example, the mainstream 6 / 14 pin combinations are ranked first, and the non-mainstream pin combinations are ranked later.

[0040] The specific process of hierarchical sorting is as follows: First, all configuration items are sorted by protocol type as the primary classification key, and then grouped into different primary groups according to protocol type. Next, within each protocol type group, they are sorted by baud rate as the secondary classification key, forming secondary subgroups. Finally, within each baud rate subgroup, they are sorted by communication pin as the tertiary classification key. After this three-level sorting, all configuration items form a hierarchical communication sequence with a clear hierarchical structure and decreasing priority.

[0041] Since some configuration items may have the same protocol type, baud rate, and pin parameters but different system identifiers (e.g., different software versions of ECUs under the same hardware interface), these configuration items are treated as parallel items under the same end node and arranged adjacently in the hierarchical communication sequence, waiting to be further distinguished by a verification algorithm.

[0042] S103. Based on the hierarchical communication sequence, send connection requests to the target vehicle in sequence, and skip all remaining configuration items under the corresponding level according to the level where the communication failed, and determine the target configuration item where the communication was successful.

[0043] Specifically, the diagnostic equipment sends connection requests to the target vehicle item by item, starting with the configuration item at the beginning of the hierarchical communication sequence. The communication hierarchy of the connection request is divided into three layers from top to bottom: protocol layer, baud rate layer, and pin layer. The communication result of each layer determines the jump logic of subsequent polling.

[0044] For example, if CAN protocol communication fails, it indicates that the target vehicle's specified system does not support the CAN protocol. In this case, all baud rate and pin configuration items under the CAN protocol type will no longer attempt communication and will directly jump to the first configuration item of the next protocol type (such as the EXCAN protocol) to continue polling. If CAN protocol layer communication succeeds but 500K baud rate layer communication fails, all pin configuration items corresponding to the 500K baud rate under the CAN protocol will be skipped, and the configuration item of the next baud rate (such as 250K) under the CAN protocol will be jumped to continue communication. If both the CAN protocol and the 500K baud rate layer succeed but pin 6 / 14 combination communication fails, the current pin combination under that baud rate will be skipped, and the next pin combination will be jumped to continue communication. This avoids unnecessary communication attempts and saves time.

[0045] By employing the aforementioned layer-by-layer skip-based fault-tolerance mechanism, the number of polling attempts required to traverse all configuration items can be significantly reduced. Assuming the configuration set contains 100 configuration items, covering 7 protocols, an average of 3 baud rates per protocol, and an average of 5 pin combinations per baud rate, if the target protocol is identified at the first protocol layer, protocol locking can be completed with a maximum of only 7 protocol layer attempts, resulting in a significant efficiency improvement compared to the traditional item-by-item polling method.

[0046] When the protocol layer, baud rate layer, and pin layer of a certain configuration item all communicate successfully, the configuration item is identified as the target configuration item with successful communication, and the system identifier matching process of S104 is entered.

[0047] In some embodiments, the ECU of the target vehicle may be in an abnormal state (e.g., unstable voltage, poor wiring harness contact) which may cause a brief communication success followed by an interruption. In this case, the diagnostic device can add a stability check after determining that the communication is successful—send three handshake frames in succession. Only when all three handshake frames receive a valid response is the configuration item confirmed as the target configuration item. Otherwise, the communication of the configuration item is considered to have failed and is skipped according to the corresponding level rules.

[0048] S104. Send the corresponding entry command to the target vehicle according to the target configuration item, and match the returned data based on the verification algorithm to determine the current system identifier of the target vehicle.

[0049] Specifically, the entry command refers to the instruction message pre-stored in the target configuration item, used to trigger the target vehicle's ECU to return system identification data. Different system identifiers correspond to different entry command formats, lengths, and function codes. The diagnostic equipment reads the entry command from the target configuration item, encapsulates it according to the corresponding protocol format, and sends it to the target vehicle. After receiving the entry command, the target vehicle's ECU returns response data containing its own system identification information.

[0050] The matching logic of the verification algorithm includes extracting the values ​​of specific bytes from the returned data, performing bitwise operations to compare these values ​​with a preset mask value corresponding to the system identifier, and determining whether a match is successful based on whether the comparison results match. For example, extracting the values ​​of several bytes from the returned data and performing a bitwise AND operation with the preset mask value; if the results are the same, a successful match is determined.

[0051] Furthermore, before determining the current system identifier of the target vehicle, if all configuration items in the configuration set have successfully communicated but no corresponding system identifier has been matched, the system identifier at the end of the hierarchical communication sequence will be used as the default model. When a communication connection is established based on the default model, the display and access points for all extended functions will be disabled, and only basic diagnostic functions will be enabled.

[0052] Specifically, when all configuration items can communicate but cannot match an accurate system identifier, it indicates that the data may be incomplete or inaccurate. While using the default model for communication can achieve basic diagnostic functions, disabling extended functions is necessary to ensure vehicle safety and prevent safety issues caused by incompatible extended functions.

[0053] S105. Establish a communication connection with the target vehicle based on the current system identifier and perform the corresponding diagnostic functions.

[0054] Specifically, the diagnostic equipment, based on the determined current system identifier, loads the corresponding communication parameters (protocol type, baud rate, pin combination, message format, etc.) to establish a stable communication session with the target vehicle's ECU. Once the session is established, the corresponding diagnostic functions can be executed. Diagnostic functions include basic diagnostic functions and extended functions. Basic diagnostic functions refer to operations involving reading and clearing the ECU status, including but not limited to reading system version information, reading fault codes (DTCs), clearing fault codes, and reading data streams. These functions have relatively low requirements for the matching accuracy of the system identifier; a smooth communication link is sufficient for execution. Extended functions refer to operations involving the active control and writing of ECU parameters, including but not limited to action testing (e.g., injector action testing, throttle self-learning), special function configuration (e.g., anti-theft matching, key programming), and code writing (e.g., ECU flashing, parameter calibration). These functions have extremely high requirements for the matching accuracy of the system identifier; any parameter deviation may lead to ECU malfunction or even damage.

[0055] In some alternative implementations, when establishing a communication connection based on the default model, since the default model is not precisely matched, enabling extended functions may lead to risks such as ECU writing errors and module lock-up due to parameter mismatches. To address this, when the diagnostic device detects that the current system is identified as the default model, it disables the display and access to all extended functions, only enabling basic diagnostic functions. The menu items corresponding to extended functions on the user interface are grayed out or hidden, thus ensuring diagnostic availability while mitigating the potential risks of write operations.

[0056] Furthermore, after determining the current system identifier of the target vehicle, the method also includes establishing and storing a mapping relationship between the current system identifier and the vehicle model path selected by the user, thus obtaining a historical mapping table. The vehicle model path refers to the path identifier obtained by the user through the diagnostic device's human-machine interface, selecting step-by-step as "Brand → Model Series → Year → System Type," for example, "Volkswagen → Passat → 2020 → Engine System." The historical mapping table can be stored as a key-value pair structure, with the vehicle model path as the key and the current system identifier as the value. When the user selects the same vehicle model path again to initiate a diagnostic, the corresponding system identifier is directly retrieved from the historical mapping table to communicate with the target vehicle, skipping the hierarchical polling process.

[0057] The historical mapping table can be stored in the diagnostic device's local storage or in a cloud server. The advantage of this is that when a user performs a diagnostic again and selects a previous vehicle model path, they can directly use the mapped system identifier for communication, eliminating the need for hierarchical polling and saving time, thus improving diagnostic efficiency.

[0058] Since there may be situations where the actual system identifier of a vehicle corresponding to the same model path changes due to secondary modifications or ECU replacement, the diagnostic equipment automatically reverts to the standard S101 process to re-execute hierarchical polling after a failure to communicate directly based on the historical mapping table. After obtaining the new system identifier, it updates the value of the corresponding model path in the historical mapping table to ensure the timeliness and accuracy of the mapping relationship.

[0059] In the above embodiments, a configuration set is constructed by retrieving the configuration database of the same brand and type of system. The configuration items are sorted hierarchically according to three preset priorities: protocol type, baud rate, and communication pin. Based on the hierarchical communication sequence, a step-by-step jump polling is performed. Finally, the current system identifier of the target vehicle is accurately matched through the verification algorithm to establish a communication connection. This achieves efficient fault tolerance and continuity of diagnostic services in the event of the first communication failure.

[0060] In the above embodiments, the sorting rules of the hierarchical communication sequence rely on a preset static priority, which is relatively fixed once configured, and can achieve good polling convergence when facing a single vehicle model or a single diagnostic task. However, in actual diagnostic scenarios, there are many vehicle models and years, significant differences in protocol and pin preferences among different models of the same brand, and a large amount of effective matching experience accumulated by the same diagnostic device over a long period of use. Static priorities are difficult to dynamically reflect the real configuration tendencies of different vehicle models, and cannot continuously optimize polling efficiency using historical matching data. At the same time, the local experience samples accumulated by a single diagnostic device are limited, making it difficult to cover the configuration characteristics of new models or niche models, resulting in a low optimization ceiling and slow convergence speed. In order to further improve the dynamic adaptation capability and cross-device collaborative optimization capability of the hierarchical communication sequence, this application embodiment also provides another communication fault tolerance method for automotive diagnostic devices. The following is combined with Figure 2 Another communication fault-tolerant method for automotive diagnostic equipment in this application embodiment is described below: Please see Figure 2 This is another flowchart illustrating a communication fault-tolerant method for an automotive diagnostic device in an embodiment of this application.

[0061] S201. When the diagnostic device fails to communicate with the designated system of the target vehicle for the first time, the configuration database of the same brand and type of system is retrieved to obtain a configuration set containing multiple configuration items.

[0062] Each configuration item corresponds to a set of protocol types, baud rates, communication pins, and a unique system identifier. Each configuration item also has a preset initial weight value, which is used to characterize the matching success tendency of the configuration item in the historical diagnostic process.

[0063] Specifically, the initial weight values ​​are uniformly set to the same baseline value when the configuration database is first deployed. As the diagnostic equipment is used subsequently, the weight values ​​will dynamically change according to the matching results, thereby transforming the configuration database from a "static parameter set" into a "dynamic knowledge base with self-learning capabilities". The specific implementation method of this step is similar to S101 in the first embodiment, and will not be described again here.

[0064] S202. Obtain the vehicle model identification information of the target vehicle.

[0065] The vehicle model identification information includes at least one of the following: the model year field in the Vehicle Identification Number (VIN), the engine displacement code, and the level characteristics of idle pins in the OBD interface.

[0066] Specifically, the method for obtaining vehicle model identification information varies depending on the type of information. For the model year field in the Vehicle Identification Number (VIN), the diagnostic equipment can read the VIN code (17 digits) stored in the target vehicle's instrument cluster or gateway module via the OBD interface. The 10th character usually corresponds to the model year (e.g., "L" represents the 2020 model, "M" represents the 2021 model). By parsing this field, the production year of the target vehicle can be quickly identified. For the engine displacement code, the diagnostic equipment can parse the 8th character in the VIN code (usually identifying the engine model and displacement), or obtain the displacement information (e.g., 1.4T, 2.0L, etc.) by reading the static calibration data of the target vehicle's engine control unit. Regarding the level characteristics of idle pins in the OBD interface, the diagnostic equipment first performs a level scan on each pin of the OBD-II interface before establishing communication, detecting the high and low level states and voltage amplitudes of unused pins. Different vehicle models have different characteristics in the distribution of idle pin levels due to differences in electrical architecture, which can serve as an auxiliary basis for coarse vehicle model identification.

[0067] It should be noted that obtaining vehicle identification information only requires satisfying at least one of the above three information requirements; it is not necessary to obtain all of them. When the VIN code cannot be read (e.g., due to a communication failure in the gateway module), the diagnostic equipment can use the level characteristics of an idle pin on the OBD interface as an alternative identification basis to ensure the robustness of this step.

[0068] S203. Based on vehicle model identification information, remove protocol types or pin combinations that are obviously mismatched from the configuration set to obtain a subset of configurations to be sorted.

[0069] Specifically, the diagnostic equipment has a pre-built mapping rule base between vehicle model identification information and configuration item characteristics. This rule base is derived from a large amount of historical diagnostic data. For example, vehicles manufactured before 2008 generally do not support CAN bus communication. Therefore, when the VIN code year field shows 2007 or earlier, all configuration items of CAN protocol type in the configuration set can be removed. Similarly, the engine systems of a certain brand's vehicles manufactured after 2015 generally use a 6 / 14 pin combination. When matching the year field, configuration items with pin combinations other than 6 / 14 pins can be removed. Through these removal operations, the size of the original configuration set is significantly reduced. For example, if the original configuration set contains 100 configuration items, after vehicle model identification and removal, only 30 configuration items may remain to be sorted, forming a subset of unsorted configurations, reducing unnecessary computation for subsequent hierarchical sorting.

[0070] S204. Sort the configuration items in the unsorted configuration subset according to their preset priorities to obtain a preliminary hierarchical communication sequence.

[0071] Specifically, the hierarchical sorting logic in this step is the same as S102 in the first embodiment, that is, the protocol type is used as the primary classification key, the baud rate as the secondary classification key, and the communication pin as the tertiary classification key for hierarchical sorting to obtain a preliminary hierarchical communication sequence. Here, "preliminary" means that the sequence has only completed the sorting based on static preset priorities and has not yet incorporated the weight information corresponding to historical matching experience, and needs to be further optimized in the next step.

[0072] S205. For different pin combination configuration items under the same protocol type and the same baud rate, the pins are rearranged in descending order of weight value to obtain an optimized hierarchical communication sequence.

[0073] Specifically, the weight value reflects the cumulative frequency and recent activity of each configuration item being successfully matched in the historical diagnostic process of the diagnostic equipment. The higher the weight value, the more times the configuration item has been matched by vehicles of the same type from the same brand in past diagnostics, and the greater the probability that it is a target configuration item.

[0074] The granularity of the secondary reordering operation is "different pin combinations under the same protocol type and baud rate". That is, the reordering only occurs at the very end of the three-level classification (pin layer) and does not disrupt the static priority order of the protocol layer and the baud rate layer. For example, under the CAN protocol -500K baud rate group, there are 4 pin combination configuration items with weight values ​​of 3.2, 1.5, 4.7 and 0.8 respectively. After secondary reordering, these 4 configuration items are rearranged in order of weight from high to low as 4.7→3.2→1.5→0.8, so that pin combinations with historically high hit rates are tried first.

[0075] In this embodiment, the design of rearranging only at the end level is adopted to balance the robustness of static rules with the flexibility of dynamic experience. The priorities of the protocol layer and baud rate layer are based on objective indicators such as protocol communication time, which have strong universality and are not easily covered by individual experience. The priority of the pin layer is highly related to vehicle model and market distribution, and is more suitable for fine adjustment through dynamic weights.

[0076] Furthermore, after determining the current system identifier in S207, the weight value corresponding to the target configuration item is incrementally updated based on the matching result. In one optional implementation, the weight value update rule is as follows: for each successful match, the weight value is increased by a fixed step (e.g., +0.5); for configuration items that fail to match multiple times consecutively, the weight is reduced by a preset decay coefficient (e.g., 10% per week) to prevent excessive accumulation of historical weights that would make it difficult for emerging configuration items to surpass them.

[0077] In some embodiments, there may be a cold start situation where the diagnostic device has just been deployed and historical matching data has not yet been accumulated. In this case, all configuration items have the same weight value in the initial stage, and the result of the secondary rearrangement is equivalent to the preliminary hierarchical communication sequence, which does not affect the normal execution of polling. As the number of uses increases, the difference in weight value gradually becomes apparent, and the optimization effect is gradually released.

[0078] S206. Based on the hierarchical communication sequence, send connection requests to the target vehicle in sequence, and skip all remaining configuration items under the corresponding level according to the level where the communication failed, and determine the target configuration item where the communication was successful.

[0079] S207. Send the corresponding entry command to the target vehicle according to the target configuration item, and match the returned data based on the verification algorithm to determine the current system identifier of the target vehicle.

[0080] It should be noted that after determining the current system identifier, the diagnostic device triggers the weight value increment update operation in S205, increments the weight value of the target configuration item by +0.5, and writes the updated weight value back to the local configuration database, providing an optimization basis for subsequent diagnostic tasks of the same brand and type of system.

[0081] S208. Establish a communication connection with the target vehicle based on the current system identifier and perform the corresponding diagnostic functions.

[0082] S209. According to the preset cycle, upload the weight values ​​of each local configuration item and the corresponding vehicle model recognition information to the cloud server to obtain the local uploaded data.

[0083] Specifically, the preset cycle can be flexibly configured based on factors such as the frequency of use of the diagnostic equipment and network conditions. For example, it can be uploaded once every 24 hours, once after every 50 diagnostic tasks are completed, or once at a fixed time each week. The uploaded data includes the weight value of each configuration item, the unique identifier of the configuration item (e.g., configuration item ID), the corresponding vehicle identification information (VIN prefix, year field, displacement code, etc.), and the device ID and version number of the diagnostic equipment itself.

[0084] In some alternative implementations, the diagnostic device anonymizes the locally uploaded data before uploading, retaining only statistical fields related to configuration optimization, and not uploading sensitive data such as complete VIN codes, user information, and vehicle owner information, in order to comply with data security and privacy protection regulations.

[0085] S210: Receive the global weight value issued by the cloud server after aggregating and calculating the local uploaded data from multiple diagnostic devices, and obtain the global weight value corresponding to each configuration item.

[0086] Specifically, after the cloud server aggregates locally uploaded data from multiple diagnostic devices across the country and even the world, it groups and aggregates the data according to the configuration item ID and vehicle model identification information. For the same configuration item in the same vehicle model identification group, it performs aggregation operations such as weighted average, median calculation or weighted by device credibility to obtain a global weight value that reflects the group's diagnostic experience.

[0087] S211. Update the weight values ​​of the corresponding configuration items in the local configuration database according to the global weight values ​​to obtain the optimized hierarchical communication sequence.

[0088] Specifically, after receiving the global weight value, the diagnostic device matches each configuration item in the local configuration database according to its configuration item ID, updating the local weight value to the global weight value sent from the cloud. For configuration items that exist in the local configuration database but are not covered by the global weight value (such as configuration items for niche car models), the original local weight value is retained unchanged.

[0089] By updating global weight values, individual diagnostic devices no longer rely solely on their limited historical diagnostic experience but can share the collective wisdom of the entire diagnostic device network. For example, if a newly launched vehicle model is successfully matched for the first time on a few diagnostic devices, the corresponding weight increase information can be quickly transmitted to all devices in the network via cloud aggregation. This allows other diagnostic devices to directly utilize the optimized polling order when they first encounter the same vehicle model, significantly shortening the adaptation cycle for new models.

[0090] After the update is completed, the diagnostic equipment will use the optimized weight values ​​to regenerate the hierarchical communication sequence in the next diagnostic communication, so as to realize the continuous evolution and optimization of the hierarchical communication sequence.

[0091] In the above embodiments, based on the static hierarchical polling of the first embodiment, configuration set pre-screening based on vehicle model identification information, dynamic secondary rearrangement based on weight values, and global weight optimization based on cloud aggregation are introduced, so that the hierarchical communication sequence has a three-layer optimization capability of "static rules + local self-learning + cloud collaboration", which improves the polling convergence speed of diagnostic equipment in complex vehicle model environments, the efficiency of new vehicle model adaptation, and the cross-device collaboration capability.

[0092] The system in the embodiments of this invention is described below from the perspective of hardware processing. Please refer to [link / reference needed]. Figure 3 This is a schematic diagram of the physical device structure of a communication fault-tolerant system for automotive diagnostic equipment provided in an embodiment of this application.

[0093] It should be noted that, Figure 3 The structure of the system shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of the present invention.

[0094] like Figure 3As shown, the system includes a CPU, which can perform various appropriate actions and processes based on a program stored in the ROM or a program loaded into the RAM from a storage portion, such as executing the methods described in the above embodiments. The RAM also stores various programs and data required for system operation. The CPU, ROM, and RAM are interconnected via a bus. I / O interfaces are also connected to the bus.

[0095] The following components are connected to the I / O interface: input sections including cameras, infrared sensors, etc.; output sections including liquid crystal displays (LCDs) and speakers, etc.; storage sections including hard drives, etc.; and communication sections including network interface cards such as LAN (Local Area Network) cards and modems, etc. The communication section performs communication processing via a network such as the Internet. Drives are also connected to the I / O interface as needed. Removable media, such as disks, optical disks, magneto-optical disks, semiconductor memories, etc., are installed on the drive as needed so that computer programs read from them can be installed into the storage section as needed.

[0096] In particular, according to embodiments of the present invention, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of the present invention include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing computer programs for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication component, and / or installed from a removable medium. When the computer program is executed by a CPU, it performs the various functions defined in the present invention.

[0097] It should be noted that the computer-readable medium shown in the embodiments of the present invention can be a computer-readable signal medium or a computer-readable storage medium, or any combination thereof. A computer-readable storage medium can be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), flash memory, optical fiber, portable compact disc read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In the present invention, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. In the present invention, a computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, wherein a computer-readable computer program is carried. The transmitted data signal can take many forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof.

[0098] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. Each block in a flowchart or block diagram may represent a module, segment, or portion of code, which contains one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram or flowchart, and combinations of blocks in a block diagram or flowchart, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0099] In another aspect, the present invention also provides a computer-readable storage medium, which may be included in the system described in the above embodiments; or it may exist independently and not assembled into the system. The storage medium carries one or more computer programs that, when executed by a processor of a system, cause the system to implement the methods provided in the above embodiments.

[0100] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit it. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

[0101] As used in the above embodiments, depending on the context, the term "when..." can be interpreted as "if...", "after...", "in response to determining...", or "in response to detecting...". Similarly, depending on the context, the phrase "when determining..." or "if (the stated condition or event) is interpreted as "if determining...", "in response to determining...", "when (the stated condition or event) is detected", or "in response to detecting (the stated condition or event)".

[0102] In the above embodiments, implementation can be achieved entirely or partially through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented entirely or partially in the form of a computer program product. The computer program product includes one or more computer instructions. When the 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 website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid-state drive), etc.

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

Claims

1. A communication fault-tolerant method for automotive diagnostic equipment, characterized in that, include: When the diagnostic device fails to communicate with the designated system of the target vehicle for the first time, it retrieves the configuration database of the same brand and type of system, and obtains a configuration set containing multiple configuration items, where each configuration item corresponds to a set of protocol type, baud rate, communication pin and unique system identifier. Based on the protocol type, baud rate, and communication pin of each configuration item in the configuration set, they are sequentially sorted according to a preset priority to obtain a hierarchical communication sequence; Based on the hierarchical communication sequence, connection requests are sent sequentially to the target vehicle, and all remaining configuration items under the corresponding level are skipped according to the level where the communication failed, so as to determine the target configuration item where the communication was successful. The corresponding entry command is sent to the target vehicle according to the target configuration item, and the returned data is matched based on the verification algorithm to determine the current system identifier of the target vehicle; A communication connection is established with the target vehicle based on the current system identifier, and corresponding diagnostic functions are performed.

2. The method according to claim 1, characterized in that, After the step of determining the current system identifier of the target vehicle, the method further includes: A mapping relationship is established and stored between the current system identifier and the vehicle model route selected by the user, thus obtaining a historical mapping table; When a user selects the same vehicle model path to initiate a diagnostic, the corresponding system identifier is directly retrieved based on the historical mapping table to communicate with the target vehicle, skipping the hierarchical polling process.

3. The method according to claim 1, characterized in that, The diagnostic functions include basic diagnostic functions and extended functions. Prior to the step of determining the current system identifier of the target vehicle, the method further includes: If all configuration items in the configuration set communicate successfully but no corresponding system identifier is matched, the system identifier at the end of the hierarchical communication sequence will be used as the default model. When a communication connection is established based on the default model, the display and access to all extended functions are disabled, and only the basic diagnostic functions are enabled.

4. The method according to claim 1, characterized in that, The matching logic of the verification algorithm includes: Extract the value of a specific byte from the returned data; The numerical value is compared with the preset mask value corresponding to the system identifier by bitwise operations, and whether the match is successful is determined based on whether the comparison results are consistent.

5. The method according to claim 1, characterized in that, After obtaining the configuration set containing multiple configuration items, the method further includes: Obtain the vehicle model identification information of the target vehicle, wherein the vehicle model identification information includes at least one of the following: the model year field in the vehicle identification number (VIN), the engine displacement code, and the level characteristics of the idle pins of the OBD interface; Based on the vehicle identification information, protocol types or pin combinations that do not match obviously in the configuration set are removed to obtain a subset of configurations to be sorted; The configuration items in the unsorted configuration subset are sorted hierarchically according to their preset priorities to obtain a preliminary hierarchical communication sequence.

6. The method according to claim 5, characterized in that, Each configuration item in the configuration database is associated with a successful matching weight value, which is generated based on the historical successful matching count of the configuration item. The method further includes: Based on the initial hierarchical communication sequence, for different pin combination configuration items under the same protocol type and the same baud rate, the pins are rearranged from high to low according to the weight values ​​to obtain the optimized hierarchical communication sequence. After determining the current system identifier, the weight value corresponding to the target configuration item is incremented and updated according to the matching result.

7. The method according to claim 6, characterized in that, The method further includes: According to a preset cycle, the weight values ​​of each local configuration item and the corresponding vehicle identification information are uploaded to the cloud server to obtain local uploaded data; Receive the global weight value issued by the cloud server after aggregating and calculating the locally uploaded data from multiple diagnostic devices, and obtain the global weight value corresponding to each configuration item; The weight values ​​of the corresponding configuration items in the local configuration database are updated based on the global weight values ​​to obtain the optimized hierarchical communication sequence.

8. A communication fault-tolerant system for automotive diagnostic equipment, characterized in that, The system includes: One or more processors and a memory; the memory is coupled to the one or more processors, the memory being used to store computer program code, the computer program code including computer instructions, the one or more processors invoking the computer instructions to cause the system to perform the method as described in any one of claims 1-7.

9. A computer-readable storage medium comprising instructions, characterized in that, When the instructions are executed on the system, the system performs the method as described in any one of claims 1-7.

10. A computer program product, characterized in that, When the computer program product is run on the system, the system performs the method as described in any one of claims 1-7.

Images