A multi-protocol adaptive-based automobile diagnosis method

Abstract

The application relates to a multi-protocol adaptive automobile diagnosis method, which comprises the following steps: determining corresponding vehicle type information and control unit configuration information based on vehicle identification information; loading diagnosis configuration data corresponding to a target vehicle from a preset database according to the vehicle type information, and determining a target control unit corresponding to the diagnosis configuration data as a diagnosis object according to the control unit configuration information; performing multi-protocol adaptive communication establishment processing on the diagnosis object; sending corresponding diagnosis operation instructions to the diagnosis object based on diagnosis instruction configuration parameters, so as to perform corresponding diagnosis function operations and obtain corresponding response data; and performing analysis processing on the response data, generating and outputting corresponding diagnosis result data. The method can automatically complete communication establishment in different communication protocol environments, significantly reduces operation complexity and error risks caused by manual selection of protocols, and can convert response data of different sources and different formats into consistent diagnosis result output.

Description

Technical Field

[0001] This invention relates to the technical field of vehicle diagnostics, and more particularly to a vehicle diagnostic method based on multi-protocol adaptive diagnostics. Background Technology

[0002] Currently, with the continuous development of automotive electronics technology, modern cars integrate a large number of electronic control units, such as the engine control module (ECM), transmission control module (TCM), anti-lock braking system (ABS), and airbag system (SRS). Each electronic control unit provides a unified fault diagnosis interface through the on-board diagnostic (OBD) system, enabling maintenance personnel to obtain vehicle operating status information using diagnostic equipment, including reading fault information, acquiring real-time data, and performing action tests, thereby achieving the detection and maintenance of vehicle systems.

[0003] However, different vehicle models and years employ different communication protocols during their design, such as the KWP2000 protocol, CAN BUS protocol, and VPW protocol. This necessitates that diagnostic equipment be adapted to the specific protocol when communicating with the vehicle. In existing technologies, diagnostic equipment typically requires technicians to manually select the communication protocol type before establishing a connection. This process is not only cumbersome but also prone to communication failures or diagnostic errors if the protocol selection is inaccurate, thus impacting diagnostic efficiency. Summary of the Invention

[0004] To address the problem of low diagnostic efficiency in existing automotive diagnostics due to difficulties in protocol adaptation, this application provides an automotive diagnostic method based on multi-protocol adaptation.

[0005] A multi-protocol adaptive vehicle diagnostic method includes:

[0006] Obtain the vehicle identification information of the target vehicle, and determine the corresponding vehicle type information and control unit configuration information based on the vehicle identification information;

[0007] Based on the vehicle type information, load the diagnostic configuration data corresponding to the target vehicle from the preset database. The diagnostic configuration data includes at least protocol configuration parameters, diagnostic command configuration parameters, and data parsing rules.

[0008] Based on the control unit configuration information, the corresponding target control unit is identified as the object to be diagnosed;

[0009] Based on the protocol configuration parameters, perform multi-protocol adaptive communication establishment processing on the object to be diagnosed;

[0010] Once the multi-protocol adaptive communication is established, a corresponding diagnostic operation command is sent to the object to be diagnosed based on the diagnostic command configuration parameters to execute the corresponding diagnostic function operation and obtain the corresponding response data.

[0011] Based on data parsing rules, the response data is parsed and processed to generate and output the corresponding diagnostic results data.

[0012] By adopting the above technical solution, by acquiring vehicle identification information and automatically matching vehicle type information and control unit configuration information, and then combining the database to load diagnostic configuration data and perform multi-protocol adaptive communication establishment processing, automatic communication establishment and diagnostic execution without manual intervention are achieved, thereby reducing operational complexity and improving overall diagnostic efficiency and accuracy.

[0013] Preferably, the step of performing multi-protocol adaptive communication establishment processing on the object to be diagnosed, according to the protocol configuration parameters, includes:

[0014] Based on the protocol configuration parameters, multiple candidate communication protocols are determined and sorted according to a preset priority order.

[0015] Select the optimal target communication protocol from the sorted candidate communication protocols, and initialize the communication interface based on the protocol parameters corresponding to the target communication protocol. The protocol parameters include at least the communication rate parameters, address parameters, and pin configuration parameters.

[0016] After completing the initialization configuration, a communication establishment request is sent to the object to be diagnosed based on the communication establishment instruction corresponding to the target communication protocol.

[0017] Receive response data returned by the object to be diagnosed, and perform matching processing based on the response data and preset response judgment rules to generate the corresponding communication establishment judgment result;

[0018] When the communication establishment determination result indicates that the communication establishment is successful, the current communication link is maintained and the multi-protocol adaptive communication establishment process is completed.

[0019] When the communication establishment determination result indicates that the communication establishment has failed, it is determined whether there are any untried candidate communication protocols. If there are, the process switches to the next candidate communication protocol and returns to the step of initializing and configuring the communication interface based on the protocol parameters corresponding to the target communication protocol. If there are no such protocols, the process is determined to be complete.

[0020] By adopting the above technical solution, multiple candidate communication protocols are sorted and communication is attempted to be established in turn. When communication fails, the system automatically switches to the next candidate protocol, forming a closed-loop protocol attempt mechanism. This enables the system to stably establish communication links in different protocol environments, thereby improving compatibility and communication success rate in multi-protocol environments.

[0021] Preferably, the step of matching response data with preset response judgment rules to generate a corresponding communication establishment judgment result includes:

[0022] The response data is processed by feature extraction to generate corresponding response feature information, which includes frame length features, identification features and temporal features.

[0023] Determine the expected feature set corresponding to the target communication protocol. The expected feature set includes the expected frame length range, the expected identifier format, and the expected response time window.

[0024] Based on the preset response judgment rules, the response feature information and the expected feature set are compared item by item, the number of feature items that meet the matching conditions is counted, and the number of feature items is compared with the preset matching threshold to generate the corresponding communication establishment judgment result.

[0025] By adopting the above technical solution, the frame length features, identification features, and timing features of the response data are extracted and compared item by item with the expected feature set of the corresponding protocol. The judgment is made based on the number of matching feature items, thereby realizing a structured judgment of the communication establishment result and improving the accuracy and reliability of communication judgment.

[0026] Preferably, before the step of sorting multiple candidate communication protocols according to a preset priority order, the following steps are included:

[0027] Based on each candidate communication protocol, a corresponding lightweight probe instruction is generated and sent to the object to be diagnosed. The lightweight probe instruction includes at least a minimum communication request unit for triggering the object to be diagnosed to return basic response information. The minimum communication request unit is composed of a protocol identifier trigger field and a basic timing control field.

[0028] Real-time reception of probe response data returned based on lightweight probe commands; and determination of matching evaluation values ​​for each candidate communication protocol.

[0029] Based on each matching evaluation value, the corresponding preset priority order is determined.

[0030] By adopting the above technical solution, a lightweight detection mechanism is introduced before protocol sorting. Based on the detection response data, the matching evaluation value of each candidate communication protocol is determined and the priority is adjusted so that the protocol that is more likely to match is tried first, thereby reducing the number of invalid communication establishments and improving communication establishment efficiency.

[0031] Preferably, the step of acquiring the vehicle identification information of the target vehicle and determining the corresponding vehicle type information and control unit configuration information based on the vehicle identification information includes:

[0032] Obtain the vehicle identification information of the target vehicle, which includes at least the vehicle identification number (VIN) and control unit identification information;

[0033] Based on the vehicle identification number (VIN), match the corresponding vehicle type information and control unit configuration information from the preset database;

[0034] If the vehicle identification number (VIN) cannot be matched with the control unit configuration information in the preset database, the corresponding control unit configuration information will be determined by supplementing it with the control unit identification information.

[0035] By adopting the above technical solution, and by combining the Vehicle Identification Number (VIN) with the control unit identification information for dual matching, supplementary identification is performed when the database cannot directly match the complete configuration. This achieves a complete determination of the vehicle and control unit configuration, thereby improving identification accuracy and enhancing the system's adaptability to complex vehicle environments.

[0036] Preferably, the step of parsing and processing the response data based on data parsing rules to generate and output the corresponding diagnostic result data includes:

[0037] When the response data is version information returned, the version information returned data is parsed based on the data parsing rules to obtain the corresponding version information parsing data. The version information parsing data includes version information, software version number, hardware version number, calibration version number, and ECU supplier information.

[0038] When the response data is fault code clearing return data, the fault code clearing return data is parsed based on the data parsing rules to obtain the corresponding fault code clearing parsing data. The fault code clearing parsing data includes at least the clearing verification success data.

[0039] When the response data is a frozen frame return data, the frozen frame return data is parsed based on the data parsing rules to generate the corresponding frozen frame parsing data. The frozen frame parsing data includes the frozen frame triggering condition, the frozen frame data item list, and the value of each data item.

[0040] When the response data is action test return data, the action test return data is parsed based on the data parsing rules to generate corresponding action test parsing data. The action test parsing data includes at least fault code existence data.

[0041] The version information parsing data, fault code clearing parsing data, freeze frame parsing data, and action test parsing data are standardized respectively to generate and output the corresponding diagnostic result data.

[0042] By adopting the above technical solution, and by classifying and parsing different types of response data such as version information, fault code clearing, freeze frames, and action tests, and by standardizing the processing, a structured output of various diagnostic results is achieved, thereby improving the readability and consistency of diagnostic data.

[0043] Preferably, the step of parsing and processing the response data based on data parsing rules to generate and output the corresponding diagnostic result data includes:

[0044] When the response data is fault code read return data, the fault code read return data is parsed based on the data parsing rules to generate the corresponding format structure code. The format type code includes single-byte status code, two-byte fault code, GM special format code, simple format code and status format code.

[0045] Based on the format structure code, determine the corresponding fault code type and fault code status, and match the corresponding fault code description information;

[0046] The fault code type, fault code status, and fault code description information are standardized to generate and output the corresponding fault code reading and display data. The diagnostic result data is included in the fault code reading and display data.

[0047] By adopting the above technical solution, and by uniformly parsing fault codes of different formats, and further determining the fault code type, fault status, and matching corresponding descriptive information, the standardized expression of fault information is achieved, thereby improving the accuracy of fault location and the intuitiveness of diagnostic results.

[0048] Preferably, the step of parsing and processing the response data based on data parsing rules to generate and output the corresponding diagnostic result data includes:

[0049] Obtain the list of data streams to be read in advance. The list of data streams to be read contains multiple data stream items, as well as the reading rules and algorithm configurations corresponding to each data stream item.

[0050] When the response data is data returned from a data stream, the corresponding actual supported items are filtered out from each data stream item based on the returned data from the data stream.

[0051] Initialize the corresponding data stream display interface based on the actual supported projects;

[0052] Once the data stream display interface is initialized, a loop reading process is executed. In each loop sub-process of the loop reading process, the returned data from the data stream is parsed based on the data parsing rules to generate data stream parsing data. The data stream parsing data is then standardized to generate the corresponding data stream display data. The diagnostic result data is included in the data stream display data.

[0053] By adopting the above technical solution, the system can continuously acquire and dynamically update the data stream by pre-acquiring the data stream support list and filtering the actual supported items, combined with a loop reading mechanism. This enables the system to reflect the operating status of the control unit in real time, thereby improving real-time monitoring capabilities.

[0054] Preferably, the step of parsing the data stream and reading the returned data based on data parsing rules to generate data stream parsing data includes:

[0055] Based on data parsing rules, the corresponding data value x is extracted from the data returned by the data stream, and the corresponding preset calculation formula or preset mapping relationship is determined.

[0056] When the data value x is numerical, it is processed based on a preset calculation formula to generate the corresponding physical quantity data. The preset calculation formula is:

[0057] y = a·x + b;

[0058] Where a and b are preset calculation parameters;

[0059] When the data value x is status data, the data value x is mapped to the corresponding identification information based on the preset mapping relationship, and the corresponding text description information is obtained from the preset database according to the identification information.

[0060] Based on physical quantity data or textual description information, generate corresponding data stream parsing data.

[0061] By adopting the above technical solution and introducing a dual-path processing mechanism of calculation formulas and mapping relationships for data stream parsing, differentiated parsing of numerical data and state data is achieved, thereby improving the flexibility and adaptability of data stream parsing.

[0062] Preferably, before the step of determining the corresponding vehicle type information and control unit configuration information based on vehicle identification information, the following steps are included:

[0063] Determine whether to enter the fast scan process; if not, proceed with the steps of determining the corresponding vehicle type information and control unit configuration information based on the vehicle identification information.

[0064] If so, determine the corresponding list of diagnostic systems based on the vehicle identification information;

[0065] Attempt to establish communication with all target control units in the list of diagnosable systems;

[0066] If one of the target control units is successfully established, the corresponding number of fault codes is read.

[0067] Based on the number of fault codes, the corresponding scan results are recorded, and a corresponding display scan report and display index window are generated based on the scan results. The display index window is used by the user to select the corresponding target control unit as the object to be diagnosed and to perform specific diagnostic operations.

[0068] By adopting the above technical solution, a rapid scanning mechanism is introduced before the diagnostic process to attempt communication between multiple control units and obtain information on the number of fault codes. This generates a scan report and an index window, enabling users to quickly locate abnormal control units and select targets for in-depth diagnosis, thereby improving overall diagnostic efficiency while ensuring diagnostic integrity.

[0069] In summary, this application includes at least one of the following beneficial technical effects:

[0070] This application achieves automatic matching of vehicle type and control unit configuration information by acquiring vehicle identification information and combining it with a preset database, enabling the system to determine the basic diagnostic environment of the current vehicle without manual intervention. By loading diagnostic configuration data corresponding to the vehicle, the protocol parameters, diagnostic commands, and data parsing rules that differ between different vehicle models are uniformly abstracted into configurable data, thereby avoiding the solidification of protocol logic and parsing logic in the program and forming a data-driven diagnostic mechanism. In the communication establishment phase, a multi-protocol adaptive processing method is introduced, which automatically matches and switches multiple candidate communication protocols according to the protocol configuration parameters, enabling the system to automatically complete communication establishment when faced with multiple communication protocols used by different vehicle models and different years, without relying on manual selection of specific protocol types. After the communication is established, corresponding diagnostic operation commands are sent to the target control unit based on unified diagnostic command configuration parameters, and the returned response data is processed through unified data parsing rules, thereby achieving standardized output of diagnostic results under different protocols and data formats. It can automatically establish communication in different communication protocol environments, significantly reducing the operational complexity and error risk caused by manual protocol selection; and by configuring and managing protocol parameters and parsing rules, the system has stronger scalability and adaptability when facing different brands and vehicle models; at the same time, through a unified data parsing mechanism, response data from different sources and in different formats can be converted into consistent diagnostic results output, improving the readability and consistency of diagnostic results. While ensuring diagnostic accuracy, it achieves a comprehensive improvement in diagnostic efficiency, compatibility and scalability. Attached Figure Description

[0071] Figure 1 This is a flowchart of a multi-protocol adaptive vehicle diagnostic method according to one embodiment of this application. Detailed Implementation

[0072] The present application will be further described in detail below with reference to the accompanying drawings.

[0073] In one embodiment, such as Figure 1 As shown, this application discloses a vehicle diagnostic method based on multi-protocol adaptive diagnostics, including:

[0074] S10. Obtain the vehicle identification information of the target vehicle, and determine the corresponding vehicle type information and control unit configuration information based on the vehicle identification information;

[0075] S20. Based on the vehicle type information, load the diagnostic configuration data corresponding to the target vehicle from the preset database. The diagnostic configuration data includes at least the protocol configuration parameters, diagnostic command configuration parameters, and data parsing rules.

[0076] S30. Based on the control unit configuration information, determine the corresponding target control unit as the object to be diagnosed;

[0077] S40. Based on the protocol configuration parameters, perform multi-protocol adaptive communication establishment processing on the object to be diagnosed.

[0078] S50. After the multi-protocol adaptive communication is established, a corresponding diagnostic operation instruction is sent to the object to be diagnosed based on the diagnostic instruction configuration parameters to execute the corresponding diagnostic function operation and obtain the corresponding response data.

[0079] S60. Based on the data parsing rules, the response data is parsed and processed to generate and output the corresponding diagnostic result data.

[0080] In this embodiment, the target vehicle can be understood as the vehicle entity currently connected to the diagnostic equipment, which establishes a connection with the diagnostic system through a physical interface, enabling the system to communicate and access its internal electronic control units. Vehicle identification information is a set of basic data used to uniquely identify the target vehicle and its configuration characteristics, typically consisting of a vehicle identification code and related identification information of the control units, used to complete vehicle identity verification and subsequent configuration matching within the system. Vehicle type information is structured descriptive data obtained based on the parsing of vehicle identification information, used to characterize the vehicle's brand, model, year, and corresponding system architecture characteristics, thus providing a matching basis for subsequent diagnostic processes. Control unit configuration information refers to the configuration information of each component within the target vehicle... The data describing the distribution and attributes of electronic control units includes at least the type identifier, communication interface information, and corresponding system category of each control unit, used to determine the set of control objects that can participate in the diagnosis. The preset database is a pre-built configuration storage unit within the system, used to centrally store diagnostic-related data corresponding to different vehicle types, including communication protocol parameters, instruction definitions, and data parsing rules, to support unified access across multiple vehicle models. Diagnostic configuration data is a set of data matching the current vehicle, loaded from the preset database, used to drive the execution logic of the entire diagnostic process. The protocol configuration parameters describe the communication characteristics of each candidate communication protocol, including communication rate, address format, and interface. The definition includes: diagnostic instruction configuration parameters, which define the instruction format and sending rules for different diagnostic functions; and data parsing rules, which perform structured parsing and transformation on the raw response data returned by the control unit. The target control unit is the specific control object that needs to be diagnosed, selected from multiple control units based on the control unit configuration information; it serves as the direct target for subsequent communication and data interaction. The object to be diagnosed is the functional definition of the target control unit in the current diagnostic process, representing the execution entity targeted by the current communication establishment and diagnostic operations. Multi-protocol adaptive communication establishment processing refers to the process by which the system, based on protocol configuration parameters, matches and selects multiple candidate communication protocols and establishes a communication link. The diagnostic process automatically tries different protocols and determines whether the connection is successful based on the response results, thus achieving adaptive connection to different communication environments. Diagnostic operation commands are control commands generated based on diagnostic command configuration parameters to trigger the control unit to execute specific diagnostic functions. They can correspond to different types of operations such as reading data, performing tests, or obtaining status. Response data refers to the raw data set returned by the control unit after receiving the diagnostic operation command. This data is usually encapsulated in a specific protocol format and needs to be parsed and processed before it can be used. Diagnostic function operations refer to the specific diagnostic behaviors performed on the control unit, including but not limited to information reading, status detection, or function verification, which are used to obtain vehicle operating status or fault information.Data parsing rules are a set of processing rules used to convert response data into identifiable information. They include field parsing methods, data transformation algorithms, and mapping relationships, and are used to transform raw data into standardized results. Diagnostic result data is structured data generated after processing by data parsing rules. It is used to intuitively reflect the operating status and diagnostic conclusions of the vehicle or control unit, and can be further used for display or recording.

[0081] The system first acquires the vehicle identification information of the target vehicle to confirm its identity and system structure, and then matches the corresponding diagnostic configuration data in a preset database to construct a diagnostic environment suitable for the current vehicle. Subsequently, based on the control unit configuration information, the system identifies the specific target control unit as the object to be diagnosed and establishes a communication link with the control unit through multi-protocol adaptive communication. After communication is established, the system generates corresponding diagnostic operation commands based on diagnostic command configuration parameters and sends them to the object to be diagnosed, thereby triggering the control unit to return response data. Finally, the system parses the response data based on data parsing rules, converting the raw data into structured diagnostic result data and outputting it. This achieves a complete closed-loop process from vehicle identification to communication establishment to data parsing, enabling the entire diagnostic process to be automatically executed in multi-protocol and multi-vehicle environments and obtain diagnostic results in a unified format.

[0082] Furthermore, according to the protocol configuration parameters, the steps for establishing multi-protocol adaptive communication for the object to be diagnosed include:

[0083] S401. Based on the protocol configuration parameters, determine multiple candidate communication protocols and sort them according to a preset priority order.

[0084] S402. Select the optimal target communication protocol from the sorted candidate communication protocols, and initialize the communication interface based on the protocol parameters corresponding to the target communication protocol. The protocol parameters include at least the communication rate parameters, address parameters, and pin configuration parameters.

[0085] S403. After completing the initialization configuration, send a communication establishment request to the object to be diagnosed based on the communication establishment instruction corresponding to the target communication protocol.

[0086] S404. Receive the response data returned by the object to be diagnosed, and perform matching processing based on the response data and the preset response judgment rules to generate the corresponding communication establishment judgment result.

[0087] S405. When the communication establishment determination result indicates that the communication establishment is successful, maintain the current communication link and determine that the multi-protocol adaptive communication establishment process is complete.

[0088] S406. When the communication establishment determination result indicates that the communication establishment has failed, determine whether there are any untried candidate communication protocols. If there are, switch to the next candidate communication protocol and return to the step of initializing the communication interface based on the protocol parameters corresponding to the target communication protocol. If there are no, determine that the multi-protocol adaptive communication establishment process is complete.

[0089] Furthermore, the step of matching the response data with preset response judgment rules to generate the corresponding communication establishment judgment result includes:

[0090] S4041. Perform feature extraction processing on the response data to generate corresponding response feature information, which includes frame length features, identification features and timing features.

[0091] S4042. Determine the expected feature set corresponding to the target communication protocol. The expected feature set includes the expected frame length range, the expected identifier format, and the expected response time window.

[0092] S4043. Based on the preset response judgment rules, the response feature information and the expected feature set are compared item by item, the number of feature items that meet the matching conditions is counted, and the number of feature items is compared with the preset matching threshold to generate the corresponding communication establishment judgment result.

[0093] In this embodiment, protocol configuration parameters can be understood as a pre-organized set of parameterized configurations for different communication protocols. These parameters describe the underlying communication and control conditions required by each protocol during the communication establishment phase. This includes hardware parameters such as communication rate, address encoding method, and physical interface occupancy, as well as software parameters such as request format, timeout limits, and response verification methods required during communication establishment. This allows the diagnostic system to complete communication preparation according to different protocol requirements without modifying the main program logic. The object to be diagnosed is the current target control unit determined after prior identification and screening. In this phase, it exists as the peer device for establishing the communication link. The diagnostic system performs protocol adaptation, request sending, and response judgment around this object. Multi-protocol adaptive communication establishment processing refers to the diagnostic system, when facing the same object to be diagnosed, not pre-fixing a single communication protocol, but constructing multiple candidate protocol paths based on protocol configuration parameters, and then completing the adaptation selection process through automatic trial and result feedback. Essentially, it is a protocol matching and link convergence mechanism for heterogeneous control units. Candidate communication protocols refer to a set of multiple potentially applicable communication protocols selected based on the current vehicle type, control unit category, and database configuration. These protocols do not take effect simultaneously but participate in the subsequent sorting and trial process as options. The preset priority order is the order rule used to arrange multiple candidate communication protocols. It can be set by comprehensively considering the vehicle platform compatibility probability, historical configuration experience, the system characteristics of the control unit, and the universality of the protocol itself. This is used to prioritize protocols more likely to succeed in establishing a connection, thereby reducing communication overhead caused by invalid switching. The target communication protocol is the protocol object currently selected from the candidate protocol set and actually entering the trial process. It is the execution entity in a given communication establishment loop, corresponding to a unique set of protocol parameters and request format. Protocol parameters are low-level configuration data that correspond one-to-one with the target communication protocol. They are used to drive the communication interface into a working state consistent with the protocol. The communication rate parameter limits the data transmission cycle and sampling reference of the interface, ensuring consistency in bit width and time scale between the sender and receiver. The address parameter identifies the target addressing mode or node identifier of the request message in this communication, enabling the sent request to be correctly routed to the target control unit. The pin configuration parameters specify the signal channels, input / output directions, and level connections used by the diagnostic interface at the physical layer, ensuring that protocol messages are transmitted via the correct physical path. The communication interface is the interface execution unit between the diagnostic device and the vehicle control network. It can be a hardware transceiver circuit or an interface management module formed by combining the driver layer and the hardware abstraction layer. In this stage, it is responsible for performing operations such as baud rate switching, pin multiplexing configuration, address loading, and transceiver mode switching according to the protocol parameters.Initialization configuration refers to the preparatory configuration process performed on the communication interface before sending a formal communication request. The purpose of this process is to ensure that the interface state, protocol timing, and physical connection conditions are consistent with the target communication protocol, thereby providing a usable basic link environment for subsequent message interaction. The communication establishment command is a predefined network entry or handshake control message for a specific target communication protocol. It is used to trigger the object under diagnosis to enter a responsive communication state or to verify whether the object under diagnosis currently supports the protocol format. The communication establishment request is the actual message behavior sent to the object under diagnosis through the communication interface, with the communication establishment command as its core content. It includes the entire process of request generation, transmission scheduling, and waiting for a return. Response data is the raw feedback information returned by the object under diagnosis after receiving the communication establishment request. This information may manifest as a normal protocol response, an error frame, partial feedback before timeout, or abnormal data that does not match the current protocol, thus requiring further judgment. The preset response judgment rule is a set of rules used to determine whether the received response data meets the conditions for establishing the current target communication protocol. It may include length constraints, identifier matching requirements, time window limits, and a minimum number of valid features, to avoid misjudging communication success based on a single field. The communication establishment judgment result is the logical output obtained by comparing the response data with the preset response judgment rule. It characterizes whether the current target communication protocol attempt has met the conditions for maintaining a communication link. The current communication link refers to the communication channel established between the diagnostic device and the object to be diagnosed after a target communication protocol has been verified as valid, and which can be continuously used for subsequent diagnostic command interaction. Maintaining the current communication link means that the protocol parameters and interface states that have been successfully established will continue to be used in subsequent diagnostic phases, without switching protocols again. Untried candidate communication protocols refer to the remaining protocol items in the current communication establishment loop that have not yet entered the actual initialization and request sending phases. Their existence determines whether the system continues to the next round of protocol attempts. Switching to the next candidate communication protocol and returning to the initialization configuration step essentially means that the system abandons the currently failed protocol path, loads new protocol parameters, and reconfigures the interface state to start the next independent communication establishment loop.

[0094] In the refined processing of response judgment, response feature information is a structured feature set extracted from the raw response data returned by the object to be diagnosed and used for subsequent comparison. Frame length features characterize the length of the current response message in terms of byte count or field occupancy, reflecting whether the response conforms to the frame structure boundaries of the target protocol. Identification features characterize protocol markers, address identifiers, control fields, or other key content that indicates protocol identity in the response message, reflecting whether the response is semantically consistent with the current protocol. Timing features characterize the time relationship from the issuance of the communication establishment request to the arrival of the response, as well as necessary response sequence characteristics, reflecting whether the current response meets the time behavior requirements of the target protocol. The expected feature set is a pre-defined reference feature template for the target communication protocol. It is not a single fixed value but a set of feature constraints composed of multiple allowable ranges and format requirements. The expected frame length range limits the acceptable length range of a legitimate response, the expected identifier format limits the valid structure of the message header, function identifier, or addressing field, and the expected response time window limits the time interval within which the control unit should return a valid response. Item-by-item comparison processing refers to mapping the extracted response feature information to the corresponding expected feature items of the target communication protocol for comparison, in order to determine whether each type of feature meets the establishment requirements of the current protocol. The number of feature items that meet the matching conditions is a numerical result obtained by statistically analyzing the item-by-item comparison results, which is used to measure the overall similarity between the current response and the target communication protocol. The preset matching threshold is a minimum pass condition set by the system in advance, used to specify at least how many of the comparable feature items must meet the requirements for the response to be considered to have reached the level of credibility for establishing a valid link. Setting this threshold can improve the robustness of the judgment and avoid misjudgment caused by occasional noise, single field errors, or local response anomalies.

[0095] The system first constructs multiple candidate communication protocols based on the protocol configuration parameters corresponding to the current vehicle and control unit, and organizes them into a queue for attempt according to a preset priority order, allowing protocols with a higher probability of success to participate in communication establishment first. Then, the system retrieves the current target communication protocol from the queue, loads the corresponding protocol parameters such as communication rate, address, and pins into the communication interface, and puts the interface's physical and logical states into a working environment matching the protocol. After the interface is prepared, the system generates and sends a communication establishment request specific to the protocol to trigger the object under diagnosis to return feedback information. After the response data arrives, the system does not directly rely on a single field to determine success or failure, but first extracts structured features from the response data, and then... The frame length, identification, and timing features are compared with the expected feature set of the target communication protocol. The number of feature items meeting the conditions is counted and compared with a preset matching threshold to form the communication establishment judgment result for this round of protocol attempts. When the judgment result shows that the current protocol meets the link establishment conditions, the system maintains the current interface configuration and protocol state, allowing it to continue serving subsequent diagnostic operations. When the judgment result shows that the current protocol does not meet the establishment conditions, the system marks the current protocol as a failed path and checks whether there are still untried candidate protocols. If so, it reloads the parameters of the next protocol and initiates a new round of communication establishment attempts until a protocol successfully establishes a link or all candidate protocols have been traversed. Through this parameter-driven, feature-based, and cyclically switching engineering processing method, the system can automatically converge to a usable protocol under different control units, different communication standards, and different response behaviors, thereby improving the communication establishment success rate and subsequent diagnostic stability in multi-protocol environments.

[0096] Furthermore, before the step of sorting multiple candidate communication protocols according to a preset priority order, the following steps are included:

[0097] S4001. Based on each candidate communication protocol, generate and send the corresponding lightweight probe instruction to the object to be diagnosed. The lightweight probe instruction includes at least a minimum communication request unit for triggering the object to be diagnosed to return basic response information. The minimum communication request unit is composed of a protocol identifier trigger field and a basic timing control field.

[0098] S4002: Receive probe response data returned based on lightweight probe commands in real time and determine the matching evaluation value of each candidate communication protocol;

[0099] S4003. Determine the corresponding preset priority order based on each matching evaluation value.

[0100] In this embodiment, candidate communication protocols refer to a group of protocols selected for evaluation based on the current vehicle type, control unit category, and preset protocol configuration parameters before entering the formal communication establishment process. These protocols do not immediately enter the complete communication establishment process but first participate in pre-detection processing to allow the system to determine the compatibility between each protocol and the current object to be diagnosed with low communication overhead. The object to be diagnosed remains the currently identified target control unit, existing as a communication counterpart for lightweight detection in this stage. It is used to provide basic response information to the diagnostic system, thus providing a basis for subsequent protocol priority adjustments. Lightweight detection commands are a type of pre-detection control message generated for candidate communication protocols. Their function is not to directly establish a complete communication session, but rather to trigger the object to be diagnosed to return basic response information that can be used to identify the degree of protocol compatibility, while minimizing initialization burden and interaction overhead. Because this type of command serves rapid evaluation rather than formal diagnosis, its message structure is constrained to a simplified form to ensure low time consumption and minimal communication resource usage during the detection process. The Minimal Communication Request Unit (MCU) is a core functional component of the lightweight probe command. It sends a basic communication trigger signal to the target object without introducing complete session control content or complex payload data, enabling the target object to return probe feedback under the physical and logical conditions corresponding to the current candidate protocol. The Protocol Identifier Trigger field is the first key element in the MCU. It characterizes the protocol identity or protocol entry characteristics corresponding to the current lightweight probe, allowing the target object to determine the communication standard or message type used in this probe. In engineering implementation, this field can be represented as a function code, identifier code, address identifier, or protocol category marker, its purpose being to induce the target object to generate an initial response related to the candidate protocol. The Basic Timing Control field is the second key element in the MCU. It limits the basic control requirements for the probe message in terms of transmission clock speed, waiting interval, or trigger timing, enabling the diagnostic system to initiate probes in a manner consistent with the basic timing behavior of the candidate protocol and providing a corresponding time reference for subsequent response sampling. Probe response data is the basic feedback information returned by the target object after receiving a lightweight probe command. It does not require meeting all the legality conditions of a complete session establishment phase, but should reflect whether a preliminary matching relationship exists between the current candidate protocol and the target object. This data can manifest as an existence response, short frame feedback, limited field return, or detectable signal changes generated within a preset time window. The matching evaluation value is a protocol adaptation metric based on the probe response data. It characterizes the preliminary matching degree between a candidate communication protocol and the current target object, allowing the diagnostic system to relatively rank different candidate protocols.This matching evaluation value does not directly replace the subsequent formal communication establishment result, but serves as a preliminary ranking criterion to guide protocols with a higher probability of success to enter the subsequent chain-building process first. The preset priority order is a protocol attempt order regenerated based on the matching evaluation values ​​of multiple candidate communication protocols. It is essentially a dynamically adjusted priority queue, allowing the originally statically configured protocol order to be corrected based on the current probe feedback, thereby improving the efficiency and hit rate of subsequent formal communication establishment.

[0101] In determining the matching evaluation value, the system typically does not perform a complete protocol parsing of the same complexity as the formal communication establishment phase on the probe response data. Instead, it adopts a low-overhead processing method geared towards rapid evaluation. Specifically, after sending a lightweight probe command, the system monitors the response of the target object in real time and extracts several basic evaluation features from the probe response data, such as whether a valid response is generated within a preset time window, the relative time position of the response, and the coarse-grained performance of the returned data in terms of length or basic format. These features are not used to precisely prove that the current protocol has successfully established a session, but rather to determine whether it has priority value to continue entering the formal attempt process. For each candidate communication protocol, the system can quickly evaluate the actually collected probe response data based on the basic probe requirements corresponding to that candidate protocol, and form a matching evaluation value for that candidate protocol accordingly. In this way, the compatibility probability of different candidate protocols after this round of probing can be converted into a sortable numerical or graded result, thus providing an objective basis for adjusting the protocol priority order.

[0102] Before formally executing the multi-protocol adaptive communication establishment process, the system does not directly proceed to complete chain establishment one by one according to the original candidate protocol list. Instead, it first constructs a corresponding lightweight probe command for each candidate communication protocol and sends a low-overhead probe request to the object to be diagnosed through a minimum communication request unit. Since the minimum communication request unit consists only of a protocol identifier trigger field and a basic timing control field, it is significantly different from the formal communication establishment request in both physical transmission and logical triggering. It does not need to carry complete session control content or perform subsequent deep interactions, thus ensuring that the probe phase does not repeatedly occupy the processing resources required for formal chain establishment. After receiving the lightweight probe command, the object to be diagnosed returns basic response information based on the protocol triggering characteristics and timing control conditions reflected in the current message. The diagnostic system then collects these probe response data in real time and forms matching evaluation values ​​for each candidate communication protocol. Subsequently, the system reorders multiple candidate communication protocols based on each matching evaluation value, placing protocols with higher initial compatibility at the top, and then uses this ordering result as the priority input for the formal multi-protocol adaptive communication establishment process. Through this engineered process of first probing, then sorting, and then formally establishing the chain, the system can predict the compatibility of different candidate protocols without significantly increasing the communication burden. This reduces the time wasted by prioritizing invalid protocols and improves the overall response speed and success rate of the communication establishment process.

[0103] Furthermore, the steps of acquiring the vehicle identification information of the target vehicle and determining the corresponding vehicle type information and control unit configuration information based on the vehicle identification information include:

[0104] S101. Obtain the vehicle identification information of the target vehicle, which includes at least the vehicle identification number (VIN) and control unit identification information.

[0105] S102. Based on the vehicle identification number (VIN), match the corresponding vehicle type information and control unit configuration information from the preset database;

[0106] S103. If the vehicle identification number (VIN) cannot be matched with the control unit configuration information in the preset database, the corresponding control unit configuration information shall be determined by supplementing the control unit identification information.

[0107] In this embodiment, vehicle identification information is used to perform basic identity verification and configuration location of the target vehicle at the beginning of the diagnostic process. This information can be obtained through a diagnostic interface or provided via external input. The Vehicle Identification Number (VIN) serves as a unique vehicle-level identifier, used for matching and searching the preset database at the vehicle level. Control unit identification information characterizes the specific type or manufacturer characteristics of each control unit within the vehicle, thus serving as supplementary identification criteria. After acquiring the vehicle identification information, the system first performs a matching operation in the preset database based on the VIN to obtain the vehicle type information and control unit configuration information corresponding to the vehicle. The control unit configuration information describes the distribution and basic attributes of each control unit in the vehicle. When the VIN fails to match complete control unit configuration information in the preset database, the system further utilizes the acquired control unit identification information to supplement and determine the missing parts, thereby completing the control unit configuration information corresponding to the current vehicle and providing the necessary configuration foundation for subsequent target control unit selection and communication establishment processing.

[0108] Furthermore, the steps of parsing and processing the response data based on data parsing rules to generate and output the corresponding diagnostic result data include:

[0109] S60111. When the response data is version information return data, the version information return data is parsed based on the data parsing rules to obtain the corresponding version information parsing data. The version information parsing data includes version information, software version number, hardware version number, calibration version number and ECU supplier information.

[0110] S60112. When the response data is fault code clearing return data, the fault code clearing return data is parsed based on the data parsing rules to obtain the corresponding fault code clearing parsing data. The fault code clearing parsing data shall at least include clearing verification success data.

[0111] S60113. When the response data is frozen frame return data, the frozen frame return data is parsed based on the data parsing rules to generate corresponding frozen frame parsing data. The frozen frame parsing data includes the frozen frame triggering condition, the frozen frame data item list, and the value of each data item.

[0112] S60114. When the response data is action test return data, the action test return data is parsed based on the data parsing rules to generate corresponding action test parsing data. The action test parsing data shall at least include fault code existence data.

[0113] S6012. Standardize the version information parsing data, fault code clearing parsing data, freeze frame parsing data, and action test parsing data respectively, and generate and output the corresponding diagnostic result data.

[0114] In this embodiment, after receiving the response data returned by the object to be diagnosed, the system first classifies and identifies the response data according to the current diagnostic operation type to determine whether it belongs to version information return data, fault code clearing return data, freeze frame return data, or action test return data. For version information return data, the system splits and identifies the corresponding relationships of each field in the response message according to preset data parsing rules, extracting the software version, hardware version, calibration version, and control unit supplier-related content, and combining them to form the corresponding version information parsing data. For fault code clearing return data, the system focuses on identifying the execution result field or status confirmation field in the response message to determine whether the clearing command was correctly received and executed by the target control unit. Based on this, fault code clearing parsing data is generated, which at least retains the result content of whether the clearing verification was successful. For freeze frame return data, the system segments and parses the response message according to the organization format of freeze frame data, identifying the condition information that triggers the freeze frame, the data items contained in the freeze frame, and the corresponding numerical content of each data item, thereby forming freeze frame parsing data. For the action test return data, the system identifies the status field in the return content according to the response rules corresponding to the action test, determines whether there are fault code related restrictions or abnormal feedback during the current action test, and organizes them into action test parsing data.

[0115] After parsing the various response data, the system further standardizes the version information parsing data, fault code clearing parsing data, freeze frame parsing data, and action test parsing data. This standardization primarily involves converting parsing results from different sources, with different field structures, and different expressions into a unified displayable data structure, ensuring a consistent display format at the output end. Specifically, the system first establishes a unified field organization method for various parsed data types, mapping different data types to preset display fields. Then, it formats the field content; for example, it converts status results into unified success or failure indicators, organizes version information into a fixed field display format, organizes data items and values ​​in freeze frames according to lists or correspondences, and organizes action test results into status prompts. After this standardization process, although the data returned by different diagnostic functions have different sources and contents, they can all be converted into display data in a unified format, facilitating output, viewing, and subsequent processing within the same diagnostic interface.

[0116] Furthermore, the steps of parsing and processing the response data based on data parsing rules to generate and output the corresponding diagnostic result data include:

[0117] S6021. When the response data is fault code read return data, the fault code read return data is parsed based on the data parsing rules to generate the corresponding format structure code. The format type code includes single-byte status code, two-byte fault code, GM special format code, simple format code and status format code.

[0118] S6022. Based on the format structure code, determine the corresponding fault code type and fault code status, and match the corresponding fault code description information.

[0119] S6023. Standardize the fault code type, fault code status, and fault code description information to generate and output the corresponding fault code reading and display data. The diagnostic result data is included in the fault code reading and display data.

[0120] In this embodiment, when the system receives response data returned by the object to be diagnosed, it first identifies the response data as fault code read return data based on the current diagnostic operation type, and then performs format parsing processing on the fault code read return data based on preset data parsing rules. During the parsing process, the system does not directly interpret the raw data uniformly, but first divides the response message into structural parts according to different communication protocols or different data structures, thereby generating a corresponding format structure code. This format structure code is used to characterize the encoding form used by the current fault code data. When the response data conforms to a single-byte status code structure, the system extracts the corresponding status information in a single-byte manner; when the response data conforms to a two-byte fault code structure, the system extracts the fault code value in a high-low byte combination manner; when the response data belongs to a GM special format, the system parses the data according to the field distribution rules corresponding to that format; when the response data is in a simple format, the system directly extracts the data according to a simplified field structure; when the response data is in a status format, the system extracts the additional status bit information while extracting the fault code value, thereby completing the unified structural processing of fault codes of different formats and generating the corresponding format structure code.

[0121] After determining the format structure code, the system performs further semantic parsing on the fault code data based on this code. First, it extracts the corresponding type identifier information from the parsed fault code value to determine whether the fault code belongs to the powertrain system, chassis system, body system, or network communication system. Simultaneously, the system combines the status bit information carried or corresponding to the format structure code to determine the current status of the fault code, identifying it as a current fault state, a historical fault state, or a pending fault state. Based on this, the system then searches and matches the fault code value in a preset database to obtain the corresponding text description information, thus forming a complete parsing result containing the fault code value, type, status, and description.

[0122] After completing the above parsing process, the system standardizes the obtained fault code types, fault code states, and fault code descriptions, unifying data from different sources, formats, and expressions into consistent display data. Specifically, the system uniformly classifies and expresses fault code types according to preset display rules, performs standard state identifier conversion on fault code states, and organizes fault code descriptions into fixed field formats, thereby generating uniformly structured fault code reading and display data. This allows the system to output fault codes in list or structured form in the diagnostic interface, ensuring a consistent display method for fault codes from different formats and sources.

[0123] It should be noted that, compared with the aforementioned parsing and processing of version information, fault code clearing, freeze frames, and action test return data, the difference in this implementation method lies in the following: During the parsing process of fault code reading return data, a format structure code is first introduced as an intermediate abstraction layer. This is used to uniformly model fault code data under different protocols and encoding formats. Subsequent type identification, status judgment, and description matching processing are then carried out based on this format structure code, thereby achieving compatible parsing of multiple fault code formats. Other types of response data are usually parsed directly according to a fixed field structure, without the need for multi-format adaptation processing. Therefore, by adding a format structure code construction step to the parsing process, this implementation method enables the system to adapt to fault code data under various encoding rules, further improving the diagnostic system's adaptability to multi-protocol and multi-vehicle vehicle environments.

[0124] Furthermore, the steps of parsing and processing the response data based on data parsing rules to generate and output the corresponding diagnostic result data include:

[0125] S6031. Obtain the pre-read data stream support list. The data stream support list records multiple data stream items for reading, as well as the reading rules and algorithm configurations corresponding to each data stream item.

[0126] S6032. When the response data is data returned from a data stream, filter out the corresponding actual supported items from each data stream item based on the data returned from the data stream.

[0127] S6033. Initialize the corresponding data stream display interface according to the actual supported projects;

[0128] S6034. After the data stream display interface is initialized, the loop reading process is executed. In each loop sub-process of the loop reading process, the data stream read return data is parsed based on the data parsing rules to generate data stream parsing data. The data stream parsing data is standardized to generate the corresponding data stream display data. The diagnostic result data is included in the data stream display data.

[0129] In this embodiment, after the system enters the data stream reading and processing stage, it first obtains a pre-read data stream support list. This list serves as a data capability description set corresponding to the current target vehicle or control unit, recording multiple readable data stream items. For each data stream item, corresponding reading rules and algorithm configurations are pre-configured. The reading rules define the acquisition method and corresponding field position of the data stream item in the communication message, while the algorithm configuration describes the data transformation method required after acquiring the raw data, such as numerical conversion relationships or state mapping relationships. Upon receiving response data, when the system determines that the response data belongs to data stream read return data, it matches and filters each data stream item in the data stream support list based on the data stream read return data. By determining whether the data fields actually returned in the response message contain the data content required by the corresponding data stream item, the system filters out the data stream items actually supported by the current control unit, generating a corresponding set of actual supported items.

[0130] After determining the actual supported items, the system initializes the corresponding data stream display interface based on these items. This ensures that each data stream item has a corresponding display position and field within the interface, establishing a one-to-one correspondence between data stream items and display units, thus providing the foundational structure for subsequent data updates. After initializing the data stream display interface, the system enters a loop reading process. During this loop, the system periodically sends data stream reading commands to the object to be diagnosed and receives the returned data stream reading data in each loop sub-process. For each received response, the system parses the returned data based on data parsing rules, extracting the data values ​​corresponding to each data stream item from the original message. It then calculates or transforms these data values ​​using the corresponding data stream item algorithm configuration, generating the corresponding data stream parsing data. Subsequently, the system standardizes the data stream parsing data, unifying the parsing results of different data stream items into a consistent display data format, such as using unified data units, unified numerical formats, or unified status expressions. This generates the corresponding data stream display data, which is then updated in real-time to the data stream display interface, allowing users to continuously observe the changes in each data stream item. Through the above-mentioned cyclic reading and real-time update mechanism, continuous monitoring and dynamic display of the operating status of the control unit are realized, so that the data stream diagnostic results can be output in a continuous, unified and readable form.

[0131] Furthermore, the step of parsing the data stream and reading the returned data based on data parsing rules to generate data stream parsing data includes:

[0132] S60341. Based on data parsing rules, extract the corresponding data value x from the data returned by reading from the data stream, and determine the corresponding preset calculation formula or preset mapping relationship;

[0133] S60342. When the data value x is numerical data, the data value x is processed based on a preset calculation formula to generate the corresponding physical quantity data. The preset calculation formula is:

[0134] y = a·x + b;

[0135] Where a and b are preset calculation parameters;

[0136] S60343. When the data value x is status data, the data value x is mapped to the corresponding identification information based on the preset mapping relationship, and the corresponding text description information is obtained from the preset database according to the identification information.

[0137] S60344. Generate corresponding data stream parsing data based on physical quantity data or text description information.

[0138] In this embodiment, when the system receives data returned from the data stream during the cyclic reading process, it first extracts the data value x corresponding to the current data stream item from the returned data based on data parsing rules. Here, the data value x is the target field value extracted from the original response message; it can be a raw numerical value directly involved in the calculation, or a state value representing a certain working state. Simultaneously, the system determines the appropriate processing path for the data value x based on the algorithm configuration corresponding to the current data stream item in the data stream support list. That is, it determines whether the subsequent processing should use a preset calculation formula for numerical conversion or a preset mapping relationship for state mapping. When the data value x corresponds to numerical data, the system substitutes it into the preset calculation formula y=a·x+b for calculation, where parameters a and b are determined by pre-configured algorithm parameters. The calculation result is used to represent the physical quantity data of the data stream item in its actual physical meaning, such as temperature, pressure, voltage, or rotational speed. In this way, the underlying numerical values ​​in the original response message that do not have direct display meaning can be converted into engineering quantity data that reflects the real-time operating status of the target control unit.

[0139] When the data value x corresponds to state-type data, the system no longer performs formula conversion. Instead, it performs identification mapping processing on the data value x based on a preset mapping relationship, mapping different values ​​to different identification information. This identification information serves as an intermediate semantic identifier, used to further retrieve corresponding text description information from a preset database, thereby converting the underlying state value into a directly understandable semantic result, such as device on, device off, function activated, or communication abnormality. After obtaining physical quantity data or text description information, the system uses it as the final parsing result of the current data stream item, generating corresponding data stream parsing data. Therefore, this implementation essentially employs a differentiated parsing mechanism for different types of data stream items: for numerical items with continuously changing characteristics, the conversion from raw values ​​to physical quantities is completed through parameterized calculation formulas; for state-type items with discrete state characteristics, the conversion from raw values ​​to semantic descriptions is completed through mapping relationships and database retrieval; finally, the two types of processing results are uniformly organized into data stream parsing data for subsequent standardized processing and display updates, thus enabling the data stream read-back data to be transformed into diagnostic results with a consistent output format and easy observation.

[0140] Furthermore, prior to the step of determining the corresponding vehicle type information and control unit configuration information based on vehicle identification information, the following steps are included:

[0141] S01. Determine whether to enter the fast scanning process. If not, proceed with the steps of determining the corresponding vehicle type information and control unit configuration information based on the vehicle identification information.

[0142] S02. If so, determine the corresponding list of diagnosable systems based on the vehicle identification information;

[0143] S03. Attempt to establish communication with all target control units in the list of diagnosable systems;

[0144] S04. If one of the target control units is successfully established, read the corresponding number of fault codes.

[0145] S05. Based on the number of fault codes, record the corresponding scan results, and generate a corresponding display scan report and display index window based on the scan results. The display index window is used for the user to select the corresponding target control unit as the object to be diagnosed and perform specific diagnostic operations.

[0146] In this embodiment, before entering the vehicle identification and configuration matching process, the system first performs a pre-process judgment to determine whether to enter the fast scan process. This judgment can be triggered based on user operation commands, system default strategies, or the current diagnostic mode. When the judgment result is that the fast scan process should not be entered, the system directly performs vehicle identification information parsing and configuration matching processing according to the conventional process. When the judgment result is that the fast scan process should be entered, the system quickly parses the system structure of the target vehicle based on the acquired vehicle identification information and extracts a list of diagnosable systems corresponding to the vehicle from a preset database. The list of diagnosable systems is used to represent the set of all systems in the current vehicle that have diagnostic capabilities. Each system corresponds to at least one target control unit, thus forming the basic object set for subsequent scanning.

[0147] After obtaining the list of diagnosable systems, the system sequentially attempts to establish communication with each target control unit in the list. This process does not enter the complete diagnostic process; instead, it only attempts to establish a basic communication link for each control unit to determine whether the control unit can be accessed by the current diagnostic equipment. If communication is successfully established, the system further sends a simplified fault code reading command to the control unit and receives the returned response data, extracting the corresponding fault code quantity information to characterize the number of faults or abnormalities currently existing in the control unit. For control units where communication establishment fails, their communication status is recorded as inaccessible or communication abnormal. After completing the communication attempts and fault code acquisition for all target control units, the system organizes and records the communication status and fault code quantity information for each control unit, forming the corresponding scan result data.

[0148] Subsequently, the system generates a corresponding display scan report based on the scan results, displaying the communication status and fault code count of each system in a unified format, allowing users to intuitively understand the distribution of anomalies across the vehicle's systems. Simultaneously, the system further constructs a corresponding display index window based on the scan results. This index window lists all scanned control units and their corresponding status information, providing an optional entry point for each control unit. This allows users to select a target control unit and designate it as the object to be diagnosed in the subsequent detailed diagnostic process, thus achieving a smooth transition from rapid scanning to specific diagnosis. Through this processing method, the system can quickly screen the entire vehicle system before formal diagnosis and guide users to select key diagnostic objects based on the screening results, improving the targeting of the diagnostic process while ensuring diagnostic efficiency.

[0149] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. 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 spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.

Claims

1. A vehicle diagnostic method based on multi-protocol adaptive methods, characterized in that, include: Obtain the vehicle identification information of the target vehicle, and determine the corresponding vehicle type information and control unit configuration information based on the vehicle identification information; Based on the vehicle type information, diagnostic configuration data corresponding to the target vehicle is loaded from a preset database. The diagnostic configuration data includes at least protocol configuration parameters, diagnostic command configuration parameters, and data parsing rules. Based on the control unit configuration information, the corresponding target control unit is determined as the object to be diagnosed; According to the protocol configuration parameters, multi-protocol adaptive communication establishment processing is performed on the object to be diagnosed; Once the multi-protocol adaptive communication establishment process is completed, a corresponding diagnostic operation instruction is sent to the object to be diagnosed based on the diagnostic instruction configuration parameters to execute the corresponding diagnostic function operation and obtain the corresponding response data. Based on the data parsing rules, the response data is parsed and processed to generate and output the corresponding diagnostic result data.

2. The vehicle diagnostic method based on multi-protocol adaptive diagnostics according to claim 1, characterized in that, The step of performing multi-protocol adaptive communication establishment processing on the object to be diagnosed according to the protocol configuration parameters includes: Based on the protocol configuration parameters, multiple candidate communication protocols are determined, and the multiple candidate communication protocols are sorted according to a preset priority order; Select the optimal target communication protocol from the sorted candidate communication protocols, and initialize the communication interface based on the protocol parameters corresponding to the target communication protocol. The protocol parameters include at least communication rate parameters, address parameters, and pin configuration parameters. After completing the initialization configuration, a communication establishment request is sent to the object to be diagnosed based on the communication establishment instruction corresponding to the target communication protocol; Receive response data returned by the object to be diagnosed, and perform matching processing based on the response data and preset response judgment rules to generate a corresponding communication establishment judgment result; When the communication establishment determination result indicates that the communication establishment is successful, the current communication link is maintained and the multi-protocol adaptive communication establishment process is completed; When the communication establishment determination result indicates that the communication establishment has failed, it is determined whether there is an untried candidate communication protocol; if there is, it switches to the next candidate communication protocol and returns to the step of initializing and configuring the communication interface based on the protocol parameters corresponding to the target communication protocol; if there is no candidate, it is determined that the multi-protocol adaptive communication establishment process is complete.

3. The vehicle diagnostic method based on multi-protocol adaptive diagnostics according to claim 2, characterized in that, The step of matching the response data with preset response determination rules to generate a corresponding communication establishment determination result includes: The response data is subjected to feature extraction processing to generate corresponding response feature information, which includes frame length features, identification features and temporal features; Determine the expected feature set corresponding to the target communication protocol, wherein the expected feature set includes the expected frame length range, the expected identifier format, and the expected response time window; Based on the preset response determination rules, the response feature information and the expected feature set are compared item by item, the number of feature items that meet the matching conditions is counted, and the number of feature items is compared with the preset matching threshold to generate the corresponding communication establishment determination result.

4. The vehicle diagnostic method based on multi-protocol adaptive diagnostics according to claim 2, characterized in that, Before the step of sorting the candidate communication protocols according to a preset priority order, the following steps are included: Based on each of the candidate communication protocols, a corresponding lightweight probe instruction is generated and sent to the object to be diagnosed. The lightweight probe instruction includes at least a minimum communication request unit for triggering the object to be diagnosed to return basic response information. The minimum communication request unit is composed of a protocol identifier trigger field and a basic timing control field. Receive the detection response data returned based on the lightweight detection command in real time, and determine the matching evaluation value of each of the candidate communication protocols; Based on each of the matching evaluation values, a corresponding preset priority order is determined.

5. The vehicle diagnostic method based on multi-protocol adaptive diagnostics according to claim 1, characterized in that, The step of acquiring the vehicle identification information of the target vehicle and determining the corresponding vehicle type information and control unit configuration information based on the vehicle identification information includes: Obtain the vehicle identification information of the target vehicle, wherein the vehicle identification information includes at least the vehicle identification number (VIN) and control unit identification information; Based on the vehicle identification number (VIN), match the corresponding vehicle type information and control unit configuration information from the preset database; If the vehicle identification number (VIN) cannot be matched with control unit configuration information in the preset database, the corresponding control unit configuration information is determined by supplementing the control unit identification information.

6. The vehicle diagnostic method based on multi-protocol adaptive diagnostics according to claim 1, characterized in that, The step of parsing and processing the response data based on the data parsing rules to generate and output the corresponding diagnostic result data includes: When the response data is version information return data, the version information return data is parsed based on the data parsing rules to obtain the corresponding version information parsing data. The version information parsing data includes version information, software version number, hardware version number, calibration version number, and ECU supplier information. When the response data is fault code clearing return data, the fault code clearing return data is parsed based on the data parsing rules to obtain the corresponding fault code clearing parsing data. The fault code clearing parsing data includes at least clearing verification success data. When the response data is frozen frame return data, the frozen frame return data is parsed based on the data parsing rules to generate corresponding frozen frame parsing data. The frozen frame parsing data includes frozen frame triggering conditions, a list of frozen frame data items, and the value of each data item. When the response data is action test return data, the action test return data is parsed based on the data parsing rules to generate corresponding action test parsing data, which includes at least fault code existence data. The version information parsing data, the fault code clearing parsing data, the freeze frame parsing data, and the action test parsing data are standardized respectively to generate and output the corresponding diagnostic result data.

7. The vehicle diagnostic method based on multi-protocol adaptive diagnostics according to claim 1, characterized in that, The step of parsing and processing the response data based on the data parsing rules to generate and output the corresponding diagnostic result data includes: When the response data is fault code read return data, the fault code read return data is parsed based on the data parsing rules to generate a corresponding format structure code. The format type code includes single-byte status code, two-byte fault code, GM special format code, simple format code, and status format code. Based on the format structure code, determine the corresponding fault code type and fault code status, and match the corresponding fault code description information; The fault code type, fault code status, and fault code description information are standardized to generate and output corresponding fault code reading and display data. The diagnostic result data is included in the fault code reading and display data.

8. The vehicle diagnostic method based on multi-protocol adaptive diagnostics according to claim 1, characterized in that, The step of parsing and processing the response data based on the data parsing rules to generate and output the corresponding diagnostic result data includes: Obtain a pre-read data stream support list, which records multiple data stream items for reading, as well as the reading rules and algorithm configurations corresponding to each data stream item; When the response data is data returned from a data stream, the corresponding actual supported items are filtered out from each of the data stream items based on the data returned from the data stream. Initialize the corresponding data stream display interface based on the actual supported projects; After the data stream display interface is initialized, a loop reading process is executed. In each loop sub-process of the loop reading process, the data stream read return data is parsed based on the data parsing rules to generate data stream parsing data. The data stream parsing data is then standardized to generate corresponding data stream display data. The diagnostic result data is included in the data stream display data.

9. The vehicle diagnostic method based on multi-protocol adaptive diagnostics according to claim 8, characterized in that, The step of parsing the returned data from the data stream based on the data parsing rules to generate parsed data for the data stream includes: Based on the data parsing rules, the corresponding data value x is extracted from the data returned by the data stream, and the corresponding preset calculation formula or preset mapping relationship is determined. When the data value x is numerical data, the data value x is processed based on the preset calculation formula to generate the corresponding physical quantity data. The preset calculation formula is: y = a·x + b; Wherein, a and b are preset calculation parameters; When the data value x is status data, the data value x is mapped to the corresponding identification information based on the preset mapping relationship, and the corresponding text description information is obtained from the preset database according to the identification information. Based on the physical quantity data or the text description information, generate corresponding data stream parsing data.

10. The vehicle diagnostic method based on multi-protocol adaptive diagnostics according to claim 1, characterized in that, Before the step of determining the corresponding vehicle type information and control unit configuration information based on the vehicle identification information, the following steps are included: Determine whether to enter the fast scanning process; if not, proceed with the step of determining the corresponding vehicle type information and control unit configuration information based on the vehicle identification information. If so, then determine the corresponding list of diagnosable systems based on the vehicle identification information; Communication attempts are made to establish operations for all target control units in the list of diagnosable systems; If one of the target control units is successfully established, the corresponding number of fault codes is read. Based on the number of fault codes, the corresponding scan results are recorded, and a corresponding display scan report and display index window are generated based on the scan results. The display index window is used for the user to select the corresponding target control unit as the object to be diagnosed and perform specific diagnostic operations.

Images