Method and apparatus for automatic adaptation of vehicle diagnostic functions

Abstract

The application discloses an automatic adaptation method and device of vehicle diagnosis function, comprising: in response to a diagnosis trigger instruction, obtaining and analyzing the identity information of the current vehicle; when the identity information analysis fails or the confidence of the analysis result is lower than the preset confidence threshold, triggering a dynamic adaptation mode, and sending a feature data acquisition request to the vehicle; receiving the response data returned by the vehicle, extracting the electronic and electrical architecture feature parameters, and matching the reference feature parameters in the preset platform feature information library to determine the platform category to which the vehicle belongs; calling the universal diagnosis service function set corresponding to the platform category from the diagnosis resource library; using the configuration difference information in the electronic and electrical architecture feature parameters to perform parameter adaptation on the universal diagnosis service function set, and generating an effective diagnosis session. The application can automatically complete diagnosis function adaptation when the vehicle identity identification fails, and improve the vehicle model adaptation compatibility and adaptation efficiency of the diagnosis equipment.

Description

Technical Field

[0001] This application relates to the field of vehicle diagnostic technology, specifically to an automatic adaptation method and device for vehicle diagnostic functions. Background Technology

[0002] With the continuous upgrading of automotive electronic and electrical architecture, platformization and modularization have become the mainstream solutions for vehicle R&D. Vehicle maintenance generally relies on OBD (On-Board Diagnostics) diagnostic equipment to perform operations such as fault reading, data stream monitoring, and actuator testing. The adaptability of diagnostic equipment to different vehicle models directly determines the efficiency of maintenance work.

[0003] The current mainstream vehicle diagnostic adaptation method in the industry adopts a static matching mechanism based on Vehicle Identification Number (VIN). The diagnostic equipment has a locally pre-stored VIN parsing database divided by individual vehicle models. After reading the vehicle's VIN code, the equipment compares it with the local database. If a match is found, the corresponding vehicle-specific diagnostic program is loaded to perform diagnostic work. However, the existing technology has the following significant drawbacks: First, the rapid pace of new car and annual model updates means that the diagnostic database updates are cyclical. Before the database is updated, the VIN of newer vehicles cannot be recognized by the equipment, directly causing the diagnostic function to fail. Second, the traditional matching mechanism uses individual vehicle models as the adaptation unit. After VIN parsing failure, it only supports manual selection of similar models, which can easily lead to communication protocol incompatibility and diagnostic command execution errors. In summary, the existing technology has insufficient automatic adaptation capability for diagnostic functions in scenarios where vehicle model recognition fails, and cannot meet the current requirements for efficient vehicle repair diagnostics.

[0004] The preceding description is intended to provide general background information and does not necessarily constitute prior art. Summary of the Invention

[0005] This application provides an automatic adaptation method and apparatus for vehicle diagnostic functions, which can automatically complete the adaptation of diagnostic functions when the vehicle identification resolution fails, thereby improving the vehicle model adaptation compatibility and adaptation efficiency of the diagnostic equipment.

[0006] In a first aspect, embodiments of this application provide an automatic adaptation method for vehicle diagnostic functions, including: In response to a diagnostic trigger command, the vehicle's current identification information is obtained and parsed. When the identity information fails to be parsed or the confidence level of the parsing result is lower than the preset confidence threshold, the dynamic adaptation mode is triggered, and a feature data acquisition request is sent to the vehicle. Receive response data returned by the vehicle based on the feature data acquisition request, and extract the electronic and electrical architecture feature parameters of the vehicle based on the response data; The extracted electronic and electrical architecture feature parameters are matched with reference feature parameters in a preset platform feature information library to determine the platform category to which the vehicle belongs; Based on the determined platform category, retrieve the set of general diagnostic service functions corresponding to the platform category from the diagnostic resource library; By utilizing the configuration difference information in the electronic and electrical architecture feature parameters, the parameters of the general diagnostic service function set are adapted to generate an effective diagnostic session for the current vehicle.

[0007] Furthermore, in some embodiments of this application, the step of obtaining the current vehicle's identification information in response to a diagnostic trigger command and parsing the identification information includes: Send an identity verification request to the vehicle; The vehicle receives the identification information returned by the vehicle, which includes at least one of the following: vehicle manufacturer information, vehicle model information, and production year information. The identity information is compared with records in the local identity resolution database. When a matching record is found, the corresponding resolution result and the confidence level of the resolution result are output; when no matching record is found, the resolution is deemed to have failed.

[0008] Furthermore, in some embodiments of this application, sending a feature data acquisition request to the vehicle includes: When the dynamic adaptation mode is triggered, a set of detection commands that match the brand information or model information of the current vehicle are selected from the preset set of detection commands. According to a preset sending order, the detection commands are sequentially sent to one or more vehicle control devices of the vehicle via the vehicle bus; Set a response waiting time window, listen for the response signal returned by the vehicle control device within the response waiting time window, and receive the response signal.

[0009] The detection command is generated based on the common communication protocol corresponding to the vehicle R&D platform. The common communication protocol is the data link layer communication protocol and / or application layer communication protocol shared by different models under the same R&D platform. The detection command is used to request the acquisition of the underlying identifier, which is used to reflect the electronic and electrical architecture version information of the vehicle.

[0010] Furthermore, in some embodiments of this application, the receiving vehicle obtains response data returned by the request based on the feature data, and extracts the electronic and electrical architecture feature parameters of the vehicle based on the response data, including: The received response data is parsed to extract feature fields, which include at least one of the following categories: platform architecture identifier field, communication protocol type field, bus node distribution field, and data verification method field. The extracted feature fields are combined according to a preset data structure to generate a feature parameter set for the current vehicle. The set of feature parameters is validated to filter out invalid or abnormal feature data, thereby obtaining the standardized electronic and electrical architecture feature parameters.

[0011] The set of characteristic parameters includes one or more of the following: platform architecture code name, communication protocol version information, bus communication rate, number and type distribution of vehicle control device nodes, data encryption algorithm type, and data verification algorithm type.

[0012] Furthermore, in some embodiments of this application, the step of matching the extracted electronic and electrical architecture feature parameters with reference feature parameters in a preset platform feature information database to determine the platform category to which the vehicle belongs includes: The electronic and electrical architecture feature parameters are compared one by one with the reference feature parameters of each platform category in the preset platform feature information database, and the similarity between the electronic and electrical architecture feature parameters and each of the reference feature parameters is calculated. The calculated similarity is compared with a preset similarity threshold. When there is a platform category with a similarity greater than or equal to the preset similarity threshold, the platform category with the highest similarity is determined as the matching result. When the similarity between the electronic and electrical architecture feature parameters and all the reference feature parameters is lower than the preset similarity threshold, the matching is determined to be unsuccessful, and a security control strategy is executed.

[0013] The reference feature parameters in the preset platform feature information library are categorized by vehicle R&D platform. Different models under the same R&D platform correspond to the same reference feature parameters, or to reference feature parameters with a similarity higher than a preset value. The preset platform feature information library is deployed in a cloud-based diagnostic resource library and / or a local diagnostic resource library.

[0014] The safety control strategy includes: locking high-risk operation functions of the vehicle, only enabling basic data reading functions, and outputting a prompt message indicating platform matching failure.

[0015] Furthermore, in some embodiments of this application, retrieving a set of general diagnostic service functions corresponding to the determined platform category from the diagnostic resource library includes: Based on the determined platform category, generate a diagnostic resource retrieval request; Send the diagnostic resource retrieval request to the diagnostic resource library, which stores the general diagnostic service function set corresponding to each platform according to platform category; The system receives a set of general diagnostic service functions that match the platform category returned by the diagnostic resource library. The set of general diagnostic service functions includes diagnostic service functions shared by various vehicle models under the platform.

[0016] The general diagnostic service function set includes at least one of the following: fault code reading function, fault code clearing function, data stream reading function, actuator action testing function, and coding parameter setting function.

[0017] Furthermore, in some embodiments of this application, the step of utilizing the configuration difference information in the electronic and electrical architecture characteristic parameters to perform parameter adaptation on the general diagnostic service function set and generate an effective diagnostic session for the current vehicle includes: The configuration difference parameters of the current vehicle are parsed from the electronic and electrical architecture feature parameters. The configuration difference parameters include at least one of the following: powertrain type, drive mode, vehicle configuration option package code, and engine displacement information. Based on the configuration difference parameters, the mapping relationship of diagnostic parameters contained in the general diagnostic service function set is reconstructed to generate a diagnostic parameter configuration table adapted to the current vehicle configuration. Based on the diagnostic parameter configuration table and the communication protocol information in the electronic and electrical architecture characteristic parameters, a diagnostic communication link is established with the current vehicle, and the effective diagnostic session is generated.

[0018] Furthermore, in some embodiments of this application, the method further includes: The user-selected diagnostic operation is executed through the effective diagnostic session, and the diagnostic results are obtained; During the diagnostic process, the response to diagnostic commands is monitored. When an abnormal response or response timeout is detected, the abnormal information is recorded, and the electronic and electrical architecture characteristic parameters are corrected based on the abnormal information. The correspondence between the corrected electronic and electrical architecture feature parameters and the current vehicle's identity information is uploaded to the cloud server to update the preset platform feature information database or the identity resolution database.

[0019] Furthermore, in some embodiments of this application, uploading the correspondence between the modified electronic and electrical architecture feature parameters and the current vehicle's identification information to a cloud server includes: Establish a mapping table between the current vehicle's identification information and the corrected electronic and electrical architecture characteristic parameters; The association mapping table is uploaded to the cloud server so that the cloud server updates the identity resolution database according to the association mapping table. When other diagnostic devices subsequently obtain the same identity information, they can directly determine the platform category of the corresponding vehicle through the updated identity resolution library without having to re-execute the dynamic adaptation mode.

[0020] Furthermore, in some embodiments of this application, the method further includes: When the confidence level of the parsing result is greater than or equal to the preset confidence threshold, the basic configuration information of the current vehicle is directly determined based on the parsing result, and the corresponding diagnostic function set is loaded using the basic configuration information; The parsing results will be used as auxiliary verification information for subsequent platform category matching.

[0021] Furthermore, in some embodiments of this application, the diagnostic resource library includes a local diagnostic resource library and a cloud-based diagnostic resource library; when retrieving a general diagnostic service function set corresponding to the platform category from the diagnostic resource library, the retrieval is first performed from the local diagnostic resource library; when the local diagnostic resource library does not contain a general diagnostic service function set corresponding to the platform category, the corresponding general diagnostic service function set is downloaded from the cloud-based diagnostic resource library and stored in the local diagnostic resource library.

[0022] Furthermore, in some embodiments of this application, the recipient of the feature data acquisition request includes the vehicle's bus gateway and / or domain controller; the feature data acquisition request is used to acquire an underlying architecture identifier, which is stored in the bus gateway and / or the domain controller and is used to uniquely indicate the vehicle's electronic and electrical architecture version information.

[0023] Furthermore, in some embodiments of this application, the feature data acquisition request includes one or more of the following detection instructions: Architecture identifier read command, used to read the platform architecture code in the preset storage area of ​​the vehicle; Communication matrix feature acquisition instruction, used to acquire the bus signal list length and / or message period parameters of the vehicle; The hardware topology acquisition command is used to acquire the number and distribution information of electronic control unit nodes mounted on the vehicle bus.

[0024] Secondly, embodiments of this application provide an automatic adaptation device for vehicle diagnostic functions, comprising: The trigger judgment module is used to respond to the diagnostic trigger command, obtain the current vehicle's identification information, and parse the identification information; The feature acquisition module is used to trigger a dynamic adaptation mode and send a feature data acquisition request to the vehicle when the identity information parsing fails or the confidence level of the parsing result is lower than a preset confidence threshold. The feature extraction module is used to receive response data returned by the vehicle based on the feature data acquisition request, and extract the electronic and electrical architecture feature parameters of the vehicle based on the response data. The platform matching module is used to match the extracted electronic and electrical architecture feature parameters with reference feature parameters in a preset platform feature information database to determine the platform category to which the vehicle belongs. The diagnostic loading module is used to retrieve a set of general diagnostic service functions corresponding to the determined platform category from the diagnostic resource library. The session generation module is used to adapt the parameters of the general diagnostic service function set by utilizing the configuration difference information in the electronic and electrical architecture feature parameters, and generate a valid diagnostic session for the current vehicle.

[0025] This application provides an automatic adaptation method and apparatus for vehicle diagnostic functions. First, it attempts to parse the vehicle's identification information for adaptation to common vehicle models. When the identification information parsing fails or the confidence level of the parsing result is below a threshold, a dynamic adaptation process is automatically triggered. Then, it sends a feature data acquisition request to the vehicle and extracts the vehicle's electronic and electrical architecture feature parameters. These parameters are then matched with a preset platform feature information database to determine the platform category to which the vehicle belongs. Based on the characteristic that vehicles on the same platform share the underlying electronic and electrical architecture, the corresponding diagnostic resource base can be obtained without relying on the identification parsing records of a single vehicle model. Subsequently, it retrieves a set of general diagnostic service functions corresponding to the platform category and uses the configuration difference information in the electronic and electrical architecture feature parameters to perform parameter adaptation on the general diagnostic service function set, enabling the platform's general diagnostic services to match the specific configuration of the current vehicle, ultimately generating a valid diagnostic session for the current vehicle. Therefore, this application can automatically complete the adaptation and activation of vehicle diagnostic functions in scenarios where vehicle identification cannot be parsed and identified through conventional static methods, breaking through the limitations of conventional identification matching mechanisms on the range of vehicle model adaptation and improving the vehicle model adaptation compatibility and efficiency of diagnostic equipment. Attached Figure Description

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

[0027] Figure 1 This is an application environment diagram of the automatic adaptation method for vehicle diagnostic functions provided in the embodiments of this application; Figure 2 This is a flowchart illustrating the automatic adaptation method for vehicle diagnostic functions provided in this application embodiment; Figure 3 This is a schematic diagram of the automatic adaptation device for vehicle diagnostic function provided in the embodiments of this application; Figure 4 This is a schematic diagram of the structure of the electronic device provided in the embodiments of this application. Detailed Implementation

[0028] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numerals in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of systems and methods consistent with those detailed in the appended claims or with some aspects of this application.

[0029] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover descriptions such as non-exclusive inclusion, so that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element. Furthermore, components, features, and elements with the same names in different embodiments of this application may have the same meaning or different meanings, the specific meaning of which must be determined by its interpretation in that specific embodiment or further in conjunction with the context of that specific embodiment.

[0030] It should be understood that the specific embodiments described herein are merely illustrative of this application and are not intended to limit this application.

[0031] In the following description, the use of suffixes such as "module," "part," or "unit" to denote elements is solely for the purpose of illustrative purposes and has no specific meaning in itself. Therefore, "module," "part," or "unit" may be used interchangeably.

[0032] To address the aforementioned technical issues, this application provides an automatic adaptation method and apparatus for vehicle diagnostic functions, which can automatically complete diagnostic function adaptation when vehicle identification resolution fails, thereby improving the vehicle model compatibility and adaptation efficiency of diagnostic equipment.

[0033] Figure 1 This is an application environment diagram of an automatic adaptation method for vehicle diagnostic functions in one embodiment. (Refer to...) Figure 1 The automatic adaptation method for vehicle diagnostic functions is applied to an automatic adaptation system for vehicle diagnostic functions. This automatic adaptation system includes a terminal 110 and a server 120. The terminal 110 and server 120 are connected via a network. The terminal 110 can be a desktop terminal or a mobile terminal; the mobile terminal can be at least one of a mobile phone, tablet, or laptop. The server 120 can be a standalone server or a server cluster consisting of multiple servers. Server 120 is configured to perform the above-mentioned automatic adaptation method for vehicle diagnostic functions, including: in response to a diagnostic trigger command, obtaining the current vehicle's identification information and parsing the identification information; when the identification information parsing fails or the confidence level of the parsing result is lower than a preset confidence threshold, triggering a dynamic adaptation mode and sending a feature data acquisition request to the vehicle; receiving the response data returned by the vehicle based on the feature data acquisition request, and extracting the vehicle's electronic and electrical architecture feature parameters based on the response data; matching the extracted electronic and electrical architecture feature parameters with reference feature parameters in a preset platform feature information library to determine the platform category to which the vehicle belongs; retrieving a set of general diagnostic service functions corresponding to the platform category from the diagnostic resource library based on the determined platform category; and using the configuration difference information in the electronic and electrical architecture feature parameters to perform parameter adaptation on the set of general diagnostic service functions to generate a valid diagnostic session for the current vehicle.

[0034] Please see Figure 2 , Figure 2 This is a flowchart illustrating an automatic adaptation method for vehicle diagnostic functions according to an embodiment of this application. This embodiment primarily uses the application of this automatic adaptation method for vehicle diagnostic functions to a server as an example for illustrative purposes. Specifically, the automatic adaptation method for vehicle diagnostic functions provided in this embodiment may include the following steps: S1. In response to the diagnostic trigger command, obtain the current vehicle's identification information and parse the identification information; Specifically, for step S1, the diagnostic trigger command is a trigger signal to start the vehicle diagnostic process. It can be actively triggered by the user through the operation interface of the diagnostic equipment, or it can be automatically generated after the diagnostic equipment detects a valid connection with the vehicle diagnostic interface. Upon receiving the diagnostic trigger command, the system first sends a read request to the vehicle's electronic control system through the vehicle communication link to obtain the identity information used to identify the vehicle's identity attributes. Then, the system parses and processes the identity information to obtain the corresponding vehicle identification result, which serves as the basis for determining the conventional static adaptation path.

[0035] For example, when a repair technician connects the diagnostic device to the vehicle's OBD diagnostic interface and clicks the "Quick Diagnosis" button on the device interface, a diagnostic trigger command is generated. The system then reads the vehicle's identification code information through the bus, parses the code, and attempts to match it to obtain the corresponding vehicle model information.

[0036] S2. When the identity information parsing fails or the confidence level of the parsing result is lower than the preset confidence level threshold, the dynamic adaptation mode is triggered, and a feature data acquisition request is sent to the vehicle. Specifically, for step S2, the preset confidence threshold is a pre-defined critical standard for determining the reliability of the identity identifier parsing result. If the identity identifier information cannot be matched at all to obtain a valid recognition result, it is determined to be a parsing failure; if only a recognition result with a low matching degree can be obtained, and the accuracy of subsequent diagnostic adaptation cannot be guaranteed, it is determined that the confidence of the parsing result is lower than the preset threshold. When either of the above two situations occurs, the conventional static adaptation path based on the identity identifier cannot be used normally, and the system automatically switches to dynamic adaptation mode, no longer relying on the identity identifier parsing result, but directly sending a feature data acquisition request to the vehicle's electronic control system to collect relevant attribute data of the vehicle's underlying electronic and electrical architecture.

[0037] For example, if the identification code of a newly launched model is not included in the system, and no valid model identification result is obtained after parsing, it is determined to be a parsing failure. The system automatically triggers the dynamic adaptation mode; then it sends a feature data acquisition request to the vehicle electronic control system to directly obtain the underlying architecture-related data of the vehicle.

[0038] S3. Receive the response data returned by the vehicle based on the feature data acquisition request, and extract the electronic and electrical architecture feature parameters of the vehicle based on the response data; Specifically, in step S3, after receiving the feature data acquisition request, the vehicle's electronic control system will respond with corresponding data based on the request content. This data carries various attribute information of the vehicle's own electronic and electrical architecture. After receiving the complete response data, the system parses and preprocesses the data to extract feature parameters that characterize the core attributes of the vehicle's electronic and electrical architecture. These parameters reflect core characteristics such as the vehicle's architecture type and underlying communication attributes, serving as the basis for subsequent platform category matching.

[0039] For example, after receiving a request to acquire feature data, the vehicle's gateway controller returns a response message containing its own architectural attribute information; after the system receives and parses the message, it extracts feature parameters that can represent the core attributes of the vehicle's electronic and electrical architecture.

[0040] S4. Match the extracted electronic and electrical architecture feature parameters with the reference feature parameters in the preset platform feature information database to determine the platform category to which the vehicle belongs; Specifically, for step S4, the preset platform feature information library is a pre-built feature database, which stores reference feature parameters corresponding to each vehicle R&D platform. Different models under the same R&D platform share the underlying electronic and electrical architecture, and therefore have consistent or highly similar reference feature parameters. During the matching process, the system will compare the electronic and electrical architecture feature parameters extracted from the current vehicle with the reference feature parameters of each platform in the library one by one. By judging the feature fit, the R&D platform with the highest feature matching degree with the current vehicle will be selected, and the platform category to which the current vehicle belongs will be finally determined.

[0041] For example, the preset platform feature information database stores reference feature parameters of different R&D platforms of multiple car companies. After the system compares the extracted vehicle feature parameters with the reference parameters of each platform one by one, it determines that the vehicle's architectural features have the highest degree of fit with the reference parameters of a certain platform, thereby determining the platform category to which the vehicle belongs.

[0042] S5. Based on the determined platform category, retrieve the set of general diagnostic service functions corresponding to the platform category from the diagnostic resource library; Specifically, for step S5, the diagnostic resource library is a database used to store various diagnostic function resources. The diagnostic resources in the library are categorized and stored according to the R&D platform type, with each platform type corresponding to a set of universal diagnostic service functions. This universal diagnostic service function set is formed by integrating diagnostic protocols and diagnostic function rules common to all models under the same R&D platform, possessing diagnostic service capabilities common to all models under that platform. After determining the platform type to which the vehicle belongs, the system can retrieve the corresponding platform's universal diagnostic service function set from the diagnostic resource library as the basic resource for adapting the diagnostic functions to the current vehicle.

[0043] For example, the diagnostic resource library stores corresponding general diagnostic function resources categorized by different R&D platforms. After determining the platform category to which the vehicle belongs, the system retrieves the general diagnostic service function set corresponding to that platform from the diagnostic resource library to obtain the general diagnostic function foundation of that platform.

[0044] S6. Utilize the configuration difference information in the electronic and electrical architecture feature parameters to adapt the parameters of the general diagnostic service function set and generate an effective diagnostic session for the current vehicle; Specifically, for step S6, in addition to the common architectural features of the platform, the electronic and electrical architecture feature parameters also include information that reflects the configuration differences between different vehicles on the same platform, reflecting the specific configuration attributes of the current vehicle. The general diagnostic service function set is a general basic resource for the entire platform and cannot directly and completely match the specific configuration of a single vehicle. Therefore, it is necessary to adjust and adapt the relevant parameters in the function set in conjunction with the configuration difference information of the current vehicle so that the diagnostic function can match the actual configuration of the current vehicle. After the parameter adaptation is completed, a valid diagnostic session that can perform various diagnostic operations normally can be generated for the current vehicle.

[0045] For example, specific configuration differences of the current vehicle can be parsed from the electronic and electrical architecture feature parameters. Based on this information, the corresponding parameters in the general diagnostic service function set can be adjusted to adapt the diagnostic function to the specific configuration of the current vehicle. After the adaptation is completed, an effective diagnostic session that can be directly carried out can be generated.

[0046] In scenarios where vehicle identification cannot be effectively parsed and recognized, this embodiment extracts the vehicle's electronic and electrical architecture features to complete platform matching and diagnostic function adaptation, effectively overcoming the coverage limitations of static identification adaptation methods and improving the vehicle model compatibility and automatic adaptation efficiency of diagnostic equipment.

[0047] Furthermore, in some embodiments, step S1, "in response to a diagnostic trigger command, obtaining the current vehicle's identification information and parsing the identification information," may specifically include: S11. Send an identity verification request to the vehicle; Specifically, in step S11, after the diagnostic device and the vehicle diagnostic interface complete the physical connection and the vehicle communication link is initialized, an identity identifier read request command is generated according to the standard format of the vehicle bus general communication protocol. This request is then sent to the vehicle-side electronic control unit responsible for storing vehicle identity information via the vehicle communication bus, triggering the vehicle to respond with the corresponding vehicle identity identifier data. The read request uses an industry-standard service format that is compatible with most vehicle electronic control systems that conform to mainstream communication protocols.

[0048] S12. Receive vehicle identification information returned by the vehicle, the identification information including at least one of the following: vehicle manufacturer information, vehicle model information, and production year information; Specifically, in step S12, after receiving a read request, the vehicle-side electronic control unit responsible for storing identity information retrieves the pre-stored vehicle identification data from its non-volatile storage area, encapsulates the data according to the frame format specified in the protocol, and then feeds it back to the diagnostic equipment via the vehicle bus. After receiving the complete feedback data, the diagnostic equipment first performs integrity and validity checks on the data. After the checks pass, it completes data parsing to obtain the corresponding identification information. This information may include one or more of the following: manufacturer information used to identify the vehicle's production origin, vehicle model information used to distinguish product series, and production year information used to identify the production batch.

[0049] S13. Compare the identity information with the records in the local identity resolution database. If a matching record is found, output the corresponding resolution result and the confidence level of the resolution result; if no matching record is found, the resolution fails. Specifically, for step S13, the diagnostic device locally stores an identity identifier parsing library. This database pre-inputs the identity identifier feature rules and matching mapping relationships corresponding to each vehicle model. Each record corresponds to an identity identifier matching rule for a known vehicle model. During the comparison process, the system performs feature matching between the parsed vehicle identity identifier information and all records in the library one by one. Based on the number of successfully matched feature fields and the accuracy of the matching, the confidence value of this parsing result is calculated. If there is a record in the library that completely matches the current identity identifier information, the corresponding vehicle model parsing result is output, along with a corresponding high confidence value. If only some feature fields can be matched, and the specific vehicle model cannot be accurately determined, an approximate parsing result and a corresponding low confidence value are output. If there are no records in the library that match the current identity identifier information, the identity identifier parsing is directly determined to have failed.

[0050] This embodiment completes the matching and confidence quantification of identity identifiers based on the local parsing library, stably and systematically completing the initial identification of vehicle identity, while providing a clear and reliable basis for subsequent switching of adaptation modes, ensuring the execution efficiency and accuracy of the identity parsing process.

[0051] Furthermore, in some embodiments, "sending a feature data acquisition request to the vehicle" in step S2 may specifically include: S21. When the dynamic adaptation mode is triggered, a set of detection commands that match the brand information or model information of the current vehicle are selected from the preset detection command set. The detection commands are generated based on the common communication protocol corresponding to the vehicle R&D platform. The common communication protocol is the data link layer communication protocol and / or application layer communication protocol shared by different models under the same R&D platform. The detection commands are used to request the underlying identifier, which is used to reflect the electronic and electrical architecture version information of the vehicle.

[0052] Specifically, for step S21, the system has a preset detection instruction set, which includes multiple sets of detection instructions adapted to different vehicle brands or model sequences. These detection instructions are generated based on the common communication protocol corresponding to the vehicle R&D platform. This common communication protocol is a data link layer communication protocol and / or application layer communication protocol shared by different models under the same R&D platform. The detection instructions are used to request and obtain a low-level identifier, which reflects the vehicle's electronic and electrical architecture version information. When the dynamic adaptation mode is triggered, the system first extracts the currently acquired vehicle-related information, including identifiable brand information or partial model information. Based on this, it selects the set of detection instructions with the highest compatibility from the preset detection instruction set as the execution instructions for this feature data collection. This ensures that subsequent requests can adapt to the vehicle's communication protocol, increasing the probability of obtaining a valid response. S22. In accordance with the preset sending order, the detection commands are sent sequentially to one or more vehicle control devices in the vehicle via the vehicle bus; Specifically, for step S22, the preset sending order is a predetermined sequence based on the functional level of the vehicle control device and the generality of the commands. It typically follows the principle of "general commands first, core devices first," ensuring that basic, general requests receive priority responses while avoiding congestion on the vehicle bus caused by multiple commands being sent simultaneously. The system sends each selected detection command one by one through the vehicle communication bus according to this preset order. The receiving targets are one or more vehicle control devices carrying electronic and electrical architecture information, such as bus gateways, domain controllers, and other core electronic control units, ensuring that commands are delivered to the control devices storing the underlying identifiers.

[0053] S23. Set a response waiting time window, listen for the response signal returned by the vehicle control device within the response waiting time window, and receive the response signal; Specifically, for step S23, the response waiting time window is a pre-set range of time for waiting for feedback from the vehicle control device. Its duration is determined based on the typical response delay of the vehicle bus and the processing speed of different control devices. This ensures that the control device has sufficient time to process requests and provide feedback, while also preventing unlimited waiting from slowing down the overall adaptation process. After each detection command is sent, the system activates the corresponding response waiting time window. During the window's duration, it continuously monitors the transmitted data on the vehicle bus, identifies the response signal corresponding to the sent detection command, and completes signal reception upon receiving a valid response. If no valid response is detected within the time window, monitoring of the command is terminated, indicating that the command has no corresponding response.

[0054] This embodiment achieves efficient and stable acquisition of the underlying identifiers reflecting the vehicle's electronic and electrical architecture version by matching and filtering the appropriate detection commands, issuing them sequentially to the corresponding vehicle control devices, and listening for responses within a limited time. This not only improves the success rate and accuracy of feature data acquisition but also reduces the occupation of vehicle bus resources by invalid communication, ensuring the execution efficiency of the dynamic adaptation process.

[0055] Furthermore, in some embodiments, step S3, "receiving response data returned by the vehicle based on the feature data acquisition request, and extracting the vehicle's electronic and electrical architecture feature parameters based on the response data," may specifically include: S31. Parse the received response data and extract feature fields. The feature fields include at least one of the following categories: platform architecture identifier field, communication protocol type field, bus node distribution field, and data verification method field. Specifically, for step S31, the received response data is the original message data transmitted by the vehicle bus. First, according to the frame format rules of the corresponding vehicle communication protocol, the original message needs to be unpacked, parsed, and decoded to remove auxiliary transmission information such as message frame headers and check bits, and extract the valid business data carried in the message. On this basis, according to the preset feature field positioning rules, the corresponding category of feature fields is identified and extracted from the valid data. The selectable field categories include the platform architecture identifier field used to identify the version of the vehicle's R&D platform, the communication protocol type field used to characterize the standard and version of the vehicle bus communication protocol, the bus node distribution field used to reflect the distribution of the vehicle bus-mounted electronic control units, and the data verification method field used to identify the data transmission verification and encryption rules. One or more of these feature fields can be extracted according to the actual scenario as the basic data characterizing the vehicle's electronic and electrical architecture attributes.

[0056] S32. Combine the extracted feature fields according to the preset data structure to generate a feature parameter set for the current vehicle; the feature parameter set includes one or more of the following: platform architecture code, communication protocol version information, bus communication rate, number and type distribution of on-board control device nodes, data encryption algorithm type, and data verification algorithm type.

[0057] Specifically, for step S32, the preset data structure is a predefined standardized data framework used to uniformly store various electronic and electrical architecture feature parameters. This framework divides data into partitions according to feature attribute categories, clearly defining the storage location and data format requirements of each field. After extracting a single type of feature field, the system fills all extracted feature fields into the corresponding partitions of the preset data structure according to their attribute categories, classifying, integrating, and structuring the scattered field data, ultimately forming a complete set of feature parameters covering multi-dimensional architecture attributes. The feature parameter set may include one or more specific parameters such as platform architecture code, communication protocol version information, bus communication rate, number and type distribution of vehicle control device nodes, data encryption algorithm type, and data verification algorithm type.

[0058] S33. Perform validity verification on the feature parameter set, filter out invalid or abnormal feature data, and obtain standardized electronic and electrical architecture feature parameters; Specifically, for step S33, validity verification refers to verifying the compliance and rationality of each parameter in the feature parameter set according to preset verification rules. Verification rules may include field format verification, numerical range verification, and logical consistency verification. Field format verification verifies whether the format of the parameter field conforms to preset specifications; numerical range verification verifies whether the parameter value is within the reasonable value range of the corresponding category; and logical consistency verification verifies whether the logical relationship between different parameters matches. During the verification process, invalid and abnormal data that do not conform to the verification rules are filtered out from the feature parameter set, and all valid feature data that passes verification is retained. These valid feature data are then formatted and standardized to obtain the final standardized electronic and electrical architecture feature parameters, which can be directly used in the subsequent platform matching process.

[0059] This embodiment, through precise field extraction, structured integration, and validity verification filtering, can efficiently extract and organize accurate and standardized electronic and electrical architecture feature parameters from vehicle response data, effectively eliminate interference from abnormal data, ensure the reliability and availability of feature parameters, and provide a stable and high-quality data foundation for subsequent vehicle platform category matching and determination.

[0060] Furthermore, in some embodiments, step S4, "matching the extracted electronic and electrical architecture feature parameters with reference feature parameters in a preset platform feature information database to determine the platform category to which the vehicle belongs," may specifically include: S41. Compare the electronic and electrical architecture feature parameters with the reference feature parameters of each platform category in the preset platform feature information library one by one, and calculate the similarity between the electronic and electrical architecture feature parameters and each reference feature parameter; the reference feature parameters in the preset platform feature information library are classified by vehicle R&D platform, and different models under the same R&D platform correspond to the same reference feature parameters, or correspond to reference feature parameters with similarity higher than the preset value; the preset platform feature information library is deployed in the cloud diagnostic resource library and / or the local diagnostic resource library.

[0061] Specifically, for step S41, the preset platform feature information library is a pre-built standardized feature database. The reference feature parameters in the library are categorized and stored by vehicle R&D platform. Different models under the same R&D platform correspond to the same reference feature parameters, or reference feature parameters with a similarity higher than the preset value, which can completely characterize the core attributes of the corresponding platform's electronic and electrical architecture. This information library can be deployed in a local diagnostic resource library and / or a cloud-based diagnostic resource library. The database at the corresponding storage location can be selected for matching operations according to the actual usage scenario. During the matching operation, the system matches and compares the standardized electronic and electrical architecture feature parameters of the current vehicle with the reference feature parameters of each platform category in the library item by item. The system can assign corresponding weights to the architecture recognition of different feature dimensions. For example, the core features of platform architecture identification are assigned higher weights, and the auxiliary features of bus node distribution are assigned slightly lower weights. The overall similarity value between the current vehicle features and each platform reference feature is obtained through weighted calculation. The higher the similarity, the higher the architectural fit between the vehicle and the corresponding platform.

[0062] S42. Compare the calculated similarity with the preset similarity threshold. When there is a platform category with a similarity greater than or equal to the preset similarity threshold, determine the platform category with the highest similarity as the matching result. Specifically, for step S42, the preset similarity threshold is a pre-set critical value used to determine whether the platform matching result is reliable and valid. This threshold is set comprehensively based on the accuracy requirements of diagnostic adaptation and is used to filter matching results with insufficient fit, ensuring the accuracy of matching judgment from the rule level. After completing the similarity calculation of all platforms, the system compares the similarity value corresponding to each platform with the preset similarity threshold one by one. If there is at least one platform category in the library whose similarity reaches or exceeds the preset threshold, it means that the platform's architecture fit with the current vehicle meets the requirements for reliable matching. At this time, the system selects the platform category with the highest similarity value from all platform categories that reach the threshold and determines it as the final result of this matching, that is, the platform category to which the current vehicle belongs.

[0063] S43. When the similarity between the electronic and electrical architecture feature parameters and all reference feature parameters is lower than a preset similarity threshold, the matching is deemed to have failed, and a safety control strategy is executed. The safety control strategy includes: locking high-risk operation functions of the vehicle, only enabling basic data reading functions, and outputting a platform matching failure message.

[0064] Specifically, for step S43, if, after comparison and calculation, the similarity between the reference feature parameters of all platform categories in the preset platform feature information database and the feature parameters of the current vehicle's electronic and electrical architecture is lower than the preset similarity threshold, it indicates that the current vehicle's architecture features do not match the characteristics of any known platforms sufficiently, and the platform category to which the vehicle belongs cannot be reliably determined. In this case, the system determines that the platform matching has failed. To avoid subsequent diagnostic operations errors and damage to the vehicle's electronic control system due to platform misjudgment, the system will immediately execute a safety control strategy after the matching fails. This strategy specifically includes: locking high-risk operation functions involving vehicle parameter modification and program flashing in the diagnostic functions, only allowing risk-free basic data reading functions such as fault code reading and basic data stream viewing, and simultaneously outputting a platform matching failure prompt message to the user, informing the user of the current adaptation status and the range of available functions.

[0065] This embodiment can accurately and reliably determine the R&D platform to which a vehicle belongs by comparing features on a platform-by-platform basis, calculating similarity metrics, and filtering thresholds. At the same time, when effective matching cannot be completed, it avoids operational risks through safety control strategies, ensuring both the matching accuracy of dynamic adaptation and the safety of diagnostic operations.

[0066] Furthermore, in some embodiments, step S5, "retrieving a set of general diagnostic service functions corresponding to the platform category from the diagnostic resource library according to the determined platform category," may specifically include: S51. Generate a diagnostic resource retrieval request based on the determined platform category; Specifically, in step S51, after determining the platform category to which the vehicle belongs, the system first extracts the unique identifier information of that platform category. Using this as the core search condition, it generates a standardized diagnostic resource retrieval request according to the standard request format agreed upon by the diagnostic resource library. This request clearly indicates the category information of the target platform and the type of resource to be retrieved, which is a general diagnostic service resource for the platform. This is used to accurately specify the retrieval target to the resource library, ensuring that the resource library can quickly locate the corresponding storage partition.

[0067] S52. Send a diagnostic resource retrieval request to the diagnostic resource library. The diagnostic resource library stores the general diagnostic service function set corresponding to each platform according to the platform category. Specifically, in step S52, the diagnostic resource library is a database used to centrally store various diagnostic function resources. Internally, it adopts a categorized storage architecture based on vehicle development platforms. Each platform category corresponds to an independent resource storage partition, which stores the set of general diagnostic service functions corresponding to that platform. All models under the same platform share this set of general diagnostic service resources, eliminating the need to store complete diagnostic function packages separately for each model, significantly reducing redundant resource storage. After generating a search request, the system sends the request to the diagnostic resource library, triggering the resource library's search and matching process.

[0068] S53. Receive a set of general diagnostic service functions returned by the diagnostic resource library that matches the platform category. The set of general diagnostic service functions includes diagnostic service functions shared by all vehicle models under this platform. The set of general diagnostic service functions includes at least one of the following: fault code reading function, fault code clearing function, data stream reading function, actuator action test function, and coding parameter setting function.

[0069] Specifically, in step S53, after the diagnostic resource library completes the retrieval and location, it feeds back the corresponding platform's general diagnostic service function set to the system. Upon receiving the resource data, the system first performs integrity and compliance checks. Once the checks pass, the resource retrieval is completed. This general diagnostic service function set is developed and integrated based on the common communication protocol and general diagnostic service rules of the corresponding R&D platform. It covers general diagnostic service capabilities supported by all models under this platform, and may include one or more of the following: fault code reading function, fault code clearing function, data stream reading function, actuator action testing function, and coding parameter setting function, thus meeting the basic diagnostic needs of models on the same platform.

[0070] This embodiment, through a diagnostic resource architecture categorized and stored by platform type, can accurately and efficiently retrieve the common diagnostic service function set of the corresponding platform based on the platform matching results. This provides a reliable resource foundation for enabling diagnostic functions in dynamically adaptable scenarios and ensures rapid adaptation of common diagnostic functions for vehicles on the same platform.

[0071] Furthermore, in some embodiments, step S6, "using configuration difference information in the electronic and electrical architecture characteristic parameters to perform parameter adaptation on the general diagnostic service function set and generate an effective diagnostic session for the current vehicle," may specifically include: S61. Parse the configuration difference parameters of the current vehicle from the electronic and electrical architecture characteristic parameters. The configuration difference parameters include at least one of the following: powertrain type, drive mode, vehicle configuration option package code, and engine displacement information. Specifically, in step S61, after retrieving the general diagnostic service function set, the system further analyzes and extracts configuration difference parameters from the previously acquired electronic and electrical architecture feature parameters. These parameters are the core differentiating attributes between different models and configuration versions under the same R&D platform. Specifically, they can cover one or more of the following: powertrain type, drive mode, vehicle configuration option package code, and engine displacement information. They can accurately characterize the actual configuration specifications of the current vehicle, providing a clear basis for differentiated adjustments to subsequent diagnostic parameters.

[0072] S62. Parse the configuration difference parameters of the current vehicle from the electronic and electrical architecture feature parameters. The configuration difference parameters include reconstructing the diagnostic parameter mapping relationship contained in the general diagnostic service function set based on the configuration difference parameters, and generating a diagnostic parameter configuration table adapted to the current vehicle configuration. Specifically, for step S62, the universal diagnostic service function set is developed for all vehicle models on the entire platform. Its built-in diagnostic parameter mapping relationship is a platform-wide version, covering the full parameter mapping of all configurations on the same platform, and cannot directly and accurately match the specific configuration of a single vehicle. Based on the parsed configuration difference parameters, the system reconstructs and adjusts the diagnostic parameter mapping relationship contained in the universal diagnostic service function set, filters out diagnostic parameter items that match the current vehicle configuration, removes parameter items that are not supported by the current configuration, and simultaneously adjusts the address mapping, data parsing rules and instruction format of the corresponding parameters. Finally, a diagnostic parameter configuration table that is fully adapted to the current vehicle configuration is generated as the core parameter basis for subsequent diagnostic communication.

[0073] S63. Parse the configuration difference parameters of the current vehicle from the electronic and electrical architecture characteristic parameters. The configuration difference parameters include establishing a diagnostic communication link with the current vehicle based on the diagnostic parameter configuration table and the communication protocol information in the electronic and electrical architecture characteristic parameters, and generating a valid diagnostic session. Specifically, for step S63, after generating the diagnostic parameter configuration table, the system combines the communication protocol information contained in the electronic and electrical architecture characteristic parameters, including the vehicle bus type, communication baud rate, diagnostic addressing mode, data verification rules, and other underlying communication attributes, and completes the handshake and link initialization of diagnostic communication with the vehicle electronic control unit according to the corresponding protocol specifications; after completing the matching and calibration of communication parameters with the generated diagnostic parameter configuration table, and confirming that the core diagnostic commands can be correctly responded to by the vehicle electronic control unit, a valid diagnostic session for the current vehicle is officially generated, under which the user can normally perform various diagnostic operations.

[0074] This embodiment, through the complete process of extracting configuration difference parameters, reconstructing diagnostic parameter mapping, and establishing a dedicated diagnostic link, can adapt the platform's general diagnostic service function set to available diagnostic capabilities that match the actual configuration of the current vehicle. This ensures both the accuracy and availability of diagnostic functions in dynamically adapted scenarios and the stability and reliability of the diagnostic communication link.

[0075] Furthermore, in some embodiments, the method further includes: S7. Perform the user-selected diagnostic operation through a valid diagnostic session and obtain the diagnostic results; Specifically, for step S7, based on the successful establishment of a valid diagnostic session, the system provides the user with an operable diagnostic function entry point. After the user selects the target diagnostic operation according to the actual testing needs, the system generates a diagnostic command that conforms to the vehicle communication specification and sends it to the vehicle's on-board control device through the stable communication link corresponding to the valid diagnostic session and the adapted diagnostic rules. After the on-board control device receives and processes the diagnostic command, it feeds back the corresponding data results to the system. The system parses, organizes and formats the returned data to obtain clear diagnostic results and presents them to the user, completing the entire process of this diagnostic operation.

[0076] S8. During the diagnostic process, monitor the response to diagnostic commands. When an abnormal response or response timeout is detected, record the abnormal information and correct the electronic and electrical architecture characteristic parameters based on the abnormal information. Specifically, for step S8, during the execution of the full diagnostic operation, the system will monitor the response status of each issued diagnostic command in real time throughout the entire cycle. The monitoring dimensions include the response return timeliness after the command is issued, the format compliance of the response data, and the execution feedback status of the response content. When a response timeout phenomenon is detected, where the command exceeds the preset waiting time without a response, or when abnormal response content such as unsupported command or invalid data address is returned, the system will automatically archive and record the abnormal information. The recorded content includes the type of abnormal command, the target object, and the specific abnormal phenomenon. At the same time, based on the abnormal information, the system will reverse analyze and deduce the deviation items in the previously obtained electronic and electrical architecture feature parameters, and adjust and correct the relevant content of the feature parameters accordingly, so that the feature parameters are more in line with the actual attributes of the vehicle's electronic and electrical architecture.

[0077] S9. Upload the correspondence between the corrected electronic and electrical architecture feature parameters and the current vehicle identification information to the cloud server to update the preset platform feature information database or identification resolution database; Specifically, for step S9, after completing the correction and optimization of the electronic and electrical architecture feature parameters, the system establishes a one-to-one mapping relationship between the current vehicle's identity information and the corrected feature parameters. This mapping relationship is encapsulated into a standard format update data packet and uploaded to the cloud server via the network channel. After receiving the update data packet, the cloud server can synchronously supplement the corrected feature parameter data into the preset platform feature information database, enriching the reference feature samples for the corresponding platform category and optimizing the accuracy of platform matching. Alternatively, it can synchronously update the association between the vehicle's identity and the corresponding platform into the identity resolution database, so that when encountering vehicles with the same identity in the future, platform identification and adaptation can be completed directly through static resolution without having to perform a dynamic adaptation process.

[0078] This embodiment, while ensuring the execution of normal diagnostic operations, corrects vehicle characteristic parameters in reverse through abnormal response feedback during the diagnostic process, and continuously iterates and optimizes the database through cloud synchronization, enabling the diagnostic adaptation capability to have self-learning attributes. This can continuously improve the accuracy of platform matching and the coverage of static analysis, and continuously enhance the vehicle model adaptation capability of the diagnostic equipment.

[0079] Furthermore, in some embodiments, step S9, "uploading the correspondence between the corrected electronic and electrical architecture feature parameters and the current vehicle's identification information to the cloud server," may specifically include: S91. Establish a mapping table between the current vehicle's identification information and the corrected electronic and electrical architecture characteristic parameters; Specifically, in step S91, after completing the correction and calibration of the electronic and electrical architecture characteristic parameters, the system uses the unique identification information of the current vehicle as the index key to bind the complete set of electronic and electrical architecture characteristic parameters verified and corrected through real-vehicle diagnostics, the matched and confirmed platform category, and the parsed configuration difference parameters, etc., and integrates them into a structured association mapping table according to a preset standardized field format. This mapping table clarifies the correspondence between the identity of a single vehicle and its underlying architecture attributes and platform affiliation. All data has been verified through actual diagnostic scenarios and has reliable accuracy and reusability.

[0080] S92. Upload the association mapping table to the cloud server so that the cloud server updates the identity resolution database according to the association mapping table; Specifically, in step S92, after generating the association mapping table, the system uploads the mapping table data packet to the cloud server via a network communication channel, attaching a data verification code during transmission to ensure data integrity. Upon receiving the data packet, the cloud server first performs dual verification of data validity and compliance. After successful verification, it extracts the correspondence between vehicle identity identifiers and platform categories and architectural features from the mapping table and synchronously updates it incrementally to the global identity identifier resolution library. This not only supplements the existing resolution library with new vehicle identity identifier entries not yet included but also optimizes the accuracy of feature parameters for existing entries, enabling continuous iterative expansion of the global resolution library.

[0081] S93. When other diagnostic devices subsequently obtain the same identity information, they can directly determine the platform category of the corresponding vehicle through the updated identity resolution library without having to re-execute the dynamic adaptation mode. Specifically, for step S93, after the cloud-based identity resolution library is updated, all diagnostic terminals connected to the cloud service can directly and accurately determine the platform category of the vehicle by comparing the read vehicle identity with the updated global resolution library when they subsequently detect vehicles carrying the same identity information through the conventional static resolution process. They can then directly retrieve the diagnostic resources of the corresponding platform to complete the adaptation without triggering the full process of feature detection, parameter extraction, and platform matching in the dynamic adaptation mode again, thus shortening the time required for vehicle model adaptation.

[0082] This embodiment achieves precise binding between vehicle identity and architectural features through an association mapping table, and realizes full-network sharing and expansion of the identity identifier resolution library through cloud synchronization. This allows the results of a single dynamic adaptation to benefit all terminal devices, significantly reducing repetitive dynamic adaptation operations, effectively improving vehicle diagnostic adaptation efficiency in all scenarios, and continuously expanding the vehicle model coverage of static resolution.

[0083] Furthermore, in some embodiments, the method further includes: When the confidence level of the analysis result is greater than or equal to the preset confidence threshold, the basic configuration information of the current vehicle is determined directly based on the analysis result, and the corresponding diagnostic function set is loaded using the basic configuration information; The parsing results will be used as auxiliary verification information for subsequent platform category matching.

[0084] Specifically, after the system completes the parsing of the vehicle's identity identifier, if the confidence level of the output parsing result reaches or exceeds a preset confidence threshold, it indicates that the vehicle's identity information can be accurately identified by the parsing library, and the static adaptation path based on the identity identifier has sufficient reliability, without triggering an additional adaptation process. At this point, the system directly extracts the vehicle's complete basic configuration information from the parsing result, covering core attributes that clearly define diagnostic adaptation requirements, such as vehicle brand, model series, production year, power specifications, and functional configuration level. Then, using this basic configuration information as the retrieval basis, the system retrieves the exclusive diagnostic function set corresponding to this model from the diagnostic resource library, quickly completing the adaptation and loading of diagnostic functions, allowing the user to directly enter the diagnostic operation process.

[0085] While completing static analysis and diagnostic function loading, the system archives the results of this identity analysis, including the vehicle's model sequence and corresponding R&D platform affiliation, as auxiliary verification for subsequent platform category matching operations. When subsequent diagnostic processes require platform-level feature matching verification or extended function adaptation, the platform association information in the analysis results can be directly accessed. On the one hand, this allows for priority comparison with the reference feature parameters of the corresponding platform, reducing the computational scope of platform matching and improving matching efficiency. On the other hand, the platform affiliation conclusion obtained from static analysis can be cross-validated with the platform matching results. If the two conclusions are consistent, the reliability of the matching result is strengthened; if there is a discrepancy, a secondary verification process can be triggered to avoid matching errors.

[0086] This embodiment employs an efficient static adaptation process when the vehicle identity can be accurately identified, ensuring adaptation efficiency in conventional diagnostic scenarios. At the same time, the static parsing results are used as auxiliary verification for platform matching, balancing execution efficiency and result accuracy in platform matching scenarios, thus achieving dual optimization of diagnostic adaptation efficiency and adaptation accuracy.

[0087] Furthermore, in some embodiments, the diagnostic resource library includes a local diagnostic resource library and a cloud-based diagnostic resource library; when retrieving a general diagnostic service function set corresponding to the platform category from the diagnostic resource library, the search is first performed from the local diagnostic resource library; when there is no general diagnostic service function set corresponding to the platform category in the local diagnostic resource library, the corresponding general diagnostic service function set is downloaded from the cloud-based diagnostic resource library and stored in the local diagnostic resource library.

[0088] Specifically, the diagnostic resource library adopts a two-tier storage architecture that combines local and cloud-based approaches, divided into two types of storage nodes: a local diagnostic resource library and a cloud-based diagnostic resource library. The local diagnostic resource library is deployed on the local storage medium of the diagnostic equipment, primarily storing general diagnostic service function sets corresponding to mainstream vehicle R&D platforms with high market penetration and frequent access. It features fast data read response speeds and does not rely on a network environment, supporting rapid diagnostic adaptation in offline scenarios. The cloud-based diagnostic resource library is deployed in a remote cloud server cluster, storing a full set of general diagnostic service function sets covering all known vehicle R&D platforms. It continuously adds diagnostic resources for R&D platforms and iterates on existing resource versions, featuring broad resource coverage and timely version updates. As a backup supplement to the local resource library, it ensures compatibility with all vehicle models across all platforms.

[0089] Once the platform category of the current vehicle is determined, the system first triggers the local search logic, using the unique identifier of the target platform as the search condition to perform a precise match search in the resource directory of the local diagnostic resource library. If the local resource library already stores the general diagnostic service function set for the corresponding platform, the resource retrieval and loading are completed directly without initiating any network requests. Due to the low latency of local storage, the diagnostic resources can be loaded and ready in a very short time, maximizing the overall execution efficiency of the dynamic adaptation process.

[0090] If the search confirms that the corresponding platform's general diagnostic service function set is not stored in the local diagnostic resource library, it indicates that the platform resource is being used for the first time by the device or has been cleared locally. The system will automatically switch to the cloud search and download path: Under network connectivity, a resource download request for the corresponding platform is sent to the cloud diagnostic resource library. After the cloud server locates the target general diagnostic service function set, it returns the complete resource package to the diagnostic device. After the device completes the resource download and integrity verification, it uses the resource for the diagnostic adaptation of the current vehicle and simultaneously stores it in the local diagnostic resource library to complete the incremental caching of local resources. When encountering the same platform vehicle model again, the system can directly retrieve the corresponding resource from the local library without repeatedly initiating a cloud download request.

[0091] This embodiment ensures rapid adaptation and offline availability in conventional scenarios through local storage, while also covering the adaptation needs of niche and newly added platforms with full cloud resources. At the same time, it uses a local caching mechanism to enable resources to be downloaded once and reused multiple times, effectively reducing repeated network requests. This improves adaptation efficiency and enhances the adaptability of diagnostic equipment to different network environments and vehicle models.

[0092] Furthermore, in some embodiments, the recipient of the feature data acquisition request includes the vehicle's bus gateway and / or domain controller; the feature data acquisition request is used to obtain the underlying architecture identifier, which is stored in the bus gateway and / or domain controller and is used to uniquely indicate the vehicle's electronic and electrical architecture version information.

[0093] Specifically, the target of the feature data acquisition request is the vehicle's bus gateway and / or domain controller. As the core communication hub of the vehicle's electronic and electrical architecture, the bus gateway undertakes the functions of cross-bus domain data forwarding, network management, and architecture version identification. The domain controller is the core control carrier of the corresponding functional domain, and has built-in architecture definition and version baseline information for the corresponding domain. Both are the core and authoritative carriers for storing underlying architecture identification data at the vehicle level. Compared with ordinary distributed control units, the architecture information stored in them is more globally unique and platform representative.

[0094] The purpose of the feature data acquisition request is to read the vehicle's underlying architecture identifier. This identifier is pre-stored in a dedicated storage area of ​​the bus gateway and / or domain controller, and corresponds one-to-one with the development platform version to which the vehicle belongs. It can uniquely and accurately indicate the specific version of the vehicle's electronic and electrical architecture and is the core identification basis for determining the vehicle's platform affiliation. Different models derived from the same development platform have a high degree of consistency in their underlying architecture identifiers, so the platform attribute of the vehicle can be quickly identified by reading this identifier.

[0095] Furthermore, in some embodiments, the feature data acquisition request includes one or more of the following probe instructions: The architecture identifier read command is used to read the platform architecture code in the preset storage area of ​​the vehicle; Communication matrix feature acquisition instructions are used to obtain the length of the vehicle's bus signal list and / or message period parameters; The hardware topology acquisition command is used to obtain information on the number and type distribution of electronic control unit nodes mounted on the vehicle bus.

[0096] Specifically, the feature data acquisition request includes one or more of the following probe instructions.

[0097] The architecture identifier read command is used to retrieve the platform architecture code from the vehicle's preset storage area. The platform architecture code is a unique identification code assigned by the automaker to the corresponding R&D platform. It is the most direct explicit identification of the platform and is usually stored in a fixed data address of the gateway. This command can directly obtain the explicit identification information of the platform, quickly completing the initial determination of the platform.

[0098] The communication matrix feature acquisition command is used to obtain core attributes of the vehicle bus communication matrix, such as the signal list length and message period parameters. The bus communication matrices of different R&D platforms follow their respective design specifications, and features such as total signal quantity, standard message period, and frame structure definition all exhibit platform-specific regularities. These are implicit architectural fingerprint features that can be used to assist in verifying platform attribution and improve matching accuracy.

[0099] The hardware topology acquisition command is used to obtain information on the number and type distribution of electronic control unit nodes mounted on the vehicle bus. Different R&D platforms have different electronic and electrical topology designs, but the number and functional type distribution of control units mounted on the bus share common platform characteristics. These characteristics are also implicit fingerprints of the architecture, complementing the previous two types of features to form a complete dimension of vehicle architecture features.

[0100] To facilitate understanding of the automatic adaptation method for vehicle diagnostic functions provided in this embodiment, the following description uses a newly launched vehicle model from a certain brand as an example to further illustrate the automatic adaptation method for vehicle diagnostic functions provided in this application embodiment. It should be understood that the specific embodiments described herein are merely illustrative of this application and are not intended to limit the scope of this application.

[0101] In a specific embodiment, the automatic adaptation method for vehicle diagnostic functions provided in this embodiment has the following specific process: 1. Basic connection and VIN pre-parsing determination.

[0102] The maintenance personnel connect the diagnostic equipment to the vehicle's OBD-II diagnostic interface. After the equipment completes the bus physical layer handshake with the vehicle, it first reads the vehicle's 17-bit VIN identification code according to the standard protocol, and then compares the read VIN code with the locally stored VIN parsing library line by line.

[0103] Since this model is a newly launched and facelifted version, there is no corresponding matching entry in the local parsing library, making it impossible to output accurate model parsing results. The parsing confidence level is only 62%, lower than the preset 85% reliability threshold, and the traditional static diagnostic process cannot be executed normally. At this time, the system automatically triggers the dynamic recognition mode and switches to an adaptive diagnostic process based on platform features.

[0104] If the local library can accurately parse the VIN (confidence ≥ 85%), it will directly enter the traditional diagnostic process as a backup adaptation path in normal scenarios.

[0105] 2. Platform-level general feature detection command issuance.

[0106] Once in dynamic recognition mode, the diagnostic equipment does not rely on the specific protocol definition of a single vehicle model. Instead, it sequentially sends a set of preset platform characteristic detection instructions to the vehicle's central gateway, powertrain domain controller, and body domain controller. This instruction set is generated based on the common underlying communication protocol of the various generations of R&D platforms under the automaker, and is designed only for platform-level general architecture addresses, without being bound to a specific vehicle model.

[0107] The detection commands issued this time include three categories: ① Architecture identifier read command: Send a read request to the reserved data block 0xF18A inside the gateway, which is specifically used to obtain the platform version code of the vehicle; ② Communication matrix characteristic command: Request to read inherent attributes of the communication layer such as bus standard message period, total length of signal list, and data verification algorithm type; ③ Hardware topology query command: Scan the number, function type and topology distribution of electronic control unit nodes mounted on the vehicle bus through the gateway.

[0108] 3. Digital feature fingerprint construction and platform clustering matching.

[0109] The diagnostic equipment receives response messages from each electronic control unit, performs protocol parsing and data extraction on the messages, filters out core feature values, and combines them to generate a unique digital feature fingerprint for the current vehicle. The feature fingerprint generated this time is: {bus protocol type: CAN-FD, communication baud rate: 5Mbps, platform architecture code name: Evo-3.0, total number of vehicle electronic control nodes: 42, data encryption method: AES-128, verification algorithm: CRC32}.

[0110] The system then compares and matches this feature fingerprint with the local / cloud platform feature database. This database stores reference features on a per-vehicle development platform basis, including only common architectural parameters of each platform and not individual entries for a single vehicle model. After weighted similarity calculation, the current vehicle feature fingerprint matches the reference features of the Evo-Platform 3.0 platform with a 97% match rate, exceeding the preset 90% reliable matching threshold. The system ultimately determines that the vehicle belongs to the Evo-Platform 3.0 platform family.

[0111] If, after comparison, the similarity between the current vehicle characteristics and all known platforms is below the safety threshold of 70%, the system will automatically execute a safety control strategy: lock high-risk operations such as coding, flashing, and forced actuator driving, and only enable read-only diagnostic functions such as fault code reading and basic information query to avoid damage to the vehicle's electronic control system due to platform misjudgment.

[0112] 4. Platform general diagnostic kernel dynamic loading and parameter adaptation.

[0113] Based on the matched Evo-Platform 3.0 platform category, the system first searches the local diagnostic resource library. After confirming that the general diagnostic package for the platform is not stored locally, it downloads the corresponding general diagnostic kernel package for the Evo-Platform 3.0 platform from the cloud diagnostic resource library via the network and caches it locally for easy access by subsequent vehicles on the same platform.

[0114] This universal diagnostic kernel is developed based on the common diagnostic protocol of all models on the Evo platform. It integrates diagnostic services common to all models on the platform, including fault code reading and clearing, real-time data stream reading, actuator action testing, basic parameter coding and other functions, which can cover the basic diagnostic needs of all derivative models on the same platform.

[0115] After downloading, the system combines the vehicle configuration difference parameters parsed from the feature fingerprint, the powertrain is a 2.0T turbocharged gasoline engine, the transmission system is an 8AT automatic transmission, the drive type is front-wheel drive, and there is no advanced intelligent driving option package. The system reconstructs the diagnostic parameter mapping table of the general diagnostic kernel in real time, removes functional modules that the current vehicle does not have, such as the four-wheel drive control system, the hybrid battery management system, and the advanced intelligent driving domain, adjusts the corresponding diagnostic addresses and data parsing coefficients, and finally generates a temporary exclusive diagnostic session adapted to the current vehicle.

[0116] 5. Diagnostic execution and self-learning iterative optimization.

[0117] The system establishes a stable diagnostic communication link with the vehicle based on the adapted diagnostic session, allowing maintenance personnel to access the diagnostic operation interface normally. In this embodiment, the maintenance personnel successfully read the P0171 lean mixture fault code stored in the engine system and completed diagnostic operations such as real-time fuel pressure monitoring and throttle valve operation testing. The entire process can be performed without waiting for the automaker to release a dedicated diagnostic software update for this model, enabling diagnosis to be performed on newly launched vehicles.

[0118] Throughout the entire diagnostic process, the system monitors the response status of each diagnostic command in real time. If any abnormal situation is detected, such as no response or unsupported return, the system automatically records the type of abnormal command, target address, and abnormal phenomenon, and reversely derives and corrects the feature fingerprint parameters of the current vehicle to optimize the accuracy of feature matching.

[0119] Upon completion of this diagnostic task, the system automatically packages and uploads the current vehicle's VIN code, corrected digital fingerprint, matched platform category, and corresponding configuration parameters to the cloud server. After verifying the data, the cloud server updates the mapping relationship between the VIN and the platform to the global VIN parsing library. This allows other diagnostic devices to directly match the vehicle model with the same VIN through static VIN parsing, eliminating the need for a dynamic recognition process. Furthermore, the system adds the corrected feature parameters to the Evo-Platform 3.0 platform's reference feature library, further optimizing the platform's matching accuracy and enabling autonomous iteration of diagnostic capabilities—becoming increasingly accurate with use.

[0120] In summary, compared with existing technologies, the automatic adaptation method for vehicle diagnostic functions provided in this embodiment completely solves the pain point of being unable to diagnose during the database update gap period after a new car is launched; it makes full use of the common architectural features of automotive platform development, transforming independent adaptation for a single model into platform-level universal adaptation, significantly improving the vehicle compatibility and adaptation efficiency of the diagnostic equipment, and at the same time achieving continuous autonomous evolution of diagnostic capabilities through a self-learning closed loop.

[0121] It should be understood that, although Figure 2 The steps in the flowchart are shown sequentially as indicated by the arrows, but these steps are not necessarily executed in the order indicated by the arrows. Unless otherwise specified herein, there is no strict order in which these steps are executed, and they can be performed in other orders. Figure 2 At least some of the steps in the process may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these sub-steps or stages is not necessarily sequential, but can be executed in turn or alternately with other steps or at least some of the sub-steps or stages of other steps.

[0122] To facilitate better implementation of the automatic adaptation method for vehicle diagnostic functions in the embodiments of this application, the embodiments of this application also provide an automatic adaptation device for vehicle diagnostic functions based on the above-described automatic adaptation method for vehicle diagnostic functions. The meanings of the terms used are the same as in the above-described automatic adaptation method for vehicle diagnostic functions, and specific implementation details can be found in the descriptions in the method embodiments.

[0123] Please see Figure 3 , Figure 3This is a schematic diagram of the structure of the automatic adaptation device for vehicle diagnostic functions provided in this application embodiment. Specifically, the automatic adaptation device for vehicle diagnostic functions may include a trigger judgment module 201, a feature acquisition module 202, a feature extraction module 203, a platform matching module 204, a diagnostic loading module 205, and a session generation module 206, as follows: The trigger judgment module 201 is used to respond to the diagnostic trigger command, obtain the current vehicle's identification information, and parse the identification information; The feature acquisition module 202 is used to trigger the dynamic adaptation mode and send a feature data acquisition request to the vehicle when the identity information parsing fails or the confidence of the parsing result is lower than the preset confidence threshold. The feature extraction module 203 is used to receive the response data returned by the vehicle based on the feature data acquisition request, and extract the electronic and electrical architecture feature parameters of the vehicle based on the response data. The platform matching module 204 is used to match the extracted electronic and electrical architecture feature parameters with reference feature parameters in the preset platform feature information library to determine the platform category to which the vehicle belongs. The diagnostic loading module 205 is used to retrieve a set of general diagnostic service functions corresponding to the platform category from the diagnostic resource library based on the determined platform category. The session generation module 206 is used to adapt the parameters of the general diagnostic service function set by utilizing the configuration difference information in the electronic and electrical architecture feature parameters, and generate a valid diagnostic session for the current vehicle.

[0124] Specific limitations regarding the automatic adaptation device for vehicle diagnostic functions can be found in the above description of the automatic adaptation method for vehicle diagnostic functions, and will not be repeated here. Each module in the aforementioned automatic adaptation device for vehicle diagnostic functions can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device in hardware form, or stored in the memory of a computer device in software form, so that the processor can call and execute the operations corresponding to each module.

[0125] The automatic adaptation device for vehicle diagnostic functions provided in this embodiment triggers dynamic adaptation when vehicle identification fails to be resolved or the confidence level is insufficient. It extracts the characteristic parameters of the vehicle's electronic and electrical architecture to determine the platform category to which the vehicle belongs, calls up the general diagnostic service function set of the corresponding platform, and combines the configuration difference information to complete parameter adaptation to generate a valid diagnostic session. It can automatically complete the adaptation and activation of vehicle diagnostic functions in scenarios where the vehicle identification cannot be resolved and identified by conventional static methods, thereby improving the vehicle model adaptation compatibility and adaptation efficiency of the diagnostic equipment.

[0126] Furthermore, embodiments of this application also provide an electronic device, such as... Figure 4 As shown, it illustrates a structural schematic diagram of the electronic device involved in the embodiments of this application, specifically: The electronic device may include components such as a processor 301 with one or more processing cores, a memory 302 with one or more computer-readable storage media, a power supply 303, and an input unit 304. Those skilled in the art will understand that... Figure 4 The electronic device structure shown does not constitute a limitation on the electronic device and may include more or fewer components than shown, or combine certain components, or have different component arrangements. Wherein: The processor 301 is the control center of the electronic device. It connects various parts of the electronic device via various interfaces and lines, and performs various functions and processes data by running or executing software programs and / or modules stored in the memory 302, and by calling data stored in the memory 302, thereby providing overall monitoring of the electronic device. Optionally, the processor 301 may include one or more processing cores; preferably, the processor 301 may integrate an application processor and a modem processor, wherein the application processor mainly handles the operating system, user interface, and applications, and the modem processor mainly handles wireless communication. It is understood that the modem processor may not be integrated into the processor 301.

[0127] The memory 302 can be used to store software programs and modules. The processor 301 executes various functional applications and automatic adaptation methods for vehicle diagnostic functions by running the software programs and modules stored in the memory 302. The memory 302 may mainly include a program storage area and a data storage area. The program storage area may store the operating system, application programs required for at least one function (such as sound playback function, image playback function, etc.), etc.; the data storage area may store data created according to the use of the electronic device, etc. In addition, the memory 302 may include high-speed random access memory, and may also include non-volatile memory, such as at least one disk storage device, flash memory device, or other volatile solid-state storage device. Accordingly, the memory 302 may also include a memory controller to provide the processor 301 with access to the memory 302.

[0128] The electronic device also includes a power supply 303 that supplies power to various components. Preferably, the power supply 303 can be logically connected to the processor 301 through a power management system, thereby enabling functions such as charging, discharging, and power consumption management through the power management system. The power supply 303 may also include one or more DC or AC power supplies, recharging systems, power fault detection circuits, power converters or inverters, power status indicators, and other arbitrary components.

[0129] The electronic device may also include an input unit 304, which can be used to receive input digital or character information and generate keyboard, mouse, joystick, optical or trackball signal inputs related to user settings and function control.

[0130] Although not shown, the electronic device may also include a display unit, etc., which will not be described in detail here. Specifically, in this embodiment, the processor 301 in the electronic device loads the executable files corresponding to the processes of one or more applications into the memory 302 according to the following instructions, and the processor 301 runs the applications stored in the memory 302 to realize various functions, as follows: In response to a diagnostic trigger command, the system acquires and parses the current vehicle's identification information. If the identification information parsing fails or the confidence level of the parsing result is lower than a preset confidence threshold, a dynamic adaptation mode is triggered, sending a feature data acquisition request to the vehicle. The system receives the response data returned by the vehicle based on the feature data acquisition request and extracts the vehicle's electronic and electrical architecture feature parameters based on the response data. The extracted electronic and electrical architecture feature parameters are matched with reference feature parameters in a preset platform feature information library to determine the platform category to which the vehicle belongs. Based on the determined platform category, the system retrieves a set of general diagnostic service functions corresponding to the platform category from the diagnostic resource library. Using the configuration difference information in the electronic and electrical architecture feature parameters, the system performs parameter adaptation on the general diagnostic service function set to generate a valid diagnostic session for the current vehicle.

[0131] For details on the implementation of each of the above operations, please refer to the previous examples, which will not be repeated here.

[0132] This application embodiment triggers dynamic adaptation when vehicle identity resolution fails or confidence is insufficient. It extracts vehicle electronic and electrical architecture feature parameters to determine the platform category to which the vehicle belongs, calls the general diagnostic service function set of the corresponding platform, and combines configuration difference information to complete parameter adaptation to generate a valid diagnostic session. It can automatically complete the adaptation and activation of vehicle diagnostic functions in scenarios where vehicle identity cannot be resolved and identified through conventional static methods, thereby improving the vehicle model adaptation compatibility and adaptation efficiency of diagnostic equipment.

[0133] Those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be performed by instructions, or by instructions controlling related hardware. These instructions can be stored in a computer-readable storage medium and loaded and executed by a processor.

[0134] Therefore, embodiments of this application provide a storage medium storing a plurality of instructions that can be loaded by a processor to execute steps in any of the automatic adaptation methods for vehicle diagnostic functions provided in embodiments of this application. For example, the instructions can execute the following steps: In response to a diagnostic trigger command, the system acquires and parses the current vehicle's identification information. If the identification information parsing fails or the confidence level of the parsing result is lower than a preset confidence threshold, a dynamic adaptation mode is triggered, sending a feature data acquisition request to the vehicle. The system receives the response data returned by the vehicle based on the feature data acquisition request and extracts the vehicle's electronic and electrical architecture feature parameters based on the response data. The extracted electronic and electrical architecture feature parameters are matched with reference feature parameters in a preset platform feature information library to determine the platform category to which the vehicle belongs. Based on the determined platform category, the system retrieves a set of general diagnostic service functions corresponding to the platform category from the diagnostic resource library. Using the configuration difference information in the electronic and electrical architecture feature parameters, the system performs parameter adaptation on the general diagnostic service function set to generate a valid diagnostic session for the current vehicle.

[0135] For details on the implementation of each of the above operations, please refer to the previous examples, which will not be repeated here.

[0136] The storage medium may include: read-only memory (ROM), random access memory (RAM), disk or optical disk, etc.

[0137] Since the instructions stored in the storage medium can execute the steps in any of the automatic adaptation methods for vehicle diagnostic functions provided in the embodiments of this application, the beneficial effects that any of the automatic adaptation methods for vehicle diagnostic functions provided in the embodiments of this application can achieve can be realized. For details, please refer to the previous embodiments, which will not be repeated here.

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

Claims

1. An automatic adaptation method for vehicle diagnostic functions, characterized in that, include: In response to a diagnostic trigger command, the vehicle's current identification information is obtained and parsed. When the identity information fails to be parsed or the confidence level of the parsing result is lower than the preset confidence threshold, the dynamic adaptation mode is triggered, and a feature data acquisition request is sent to the vehicle. Receive response data returned by the vehicle based on the feature data acquisition request, and extract the electronic and electrical architecture feature parameters of the vehicle based on the response data; The extracted electronic and electrical architecture feature parameters are matched with reference feature parameters in a preset platform feature information library to determine the platform category to which the vehicle belongs; Based on the determined platform category, retrieve the set of general diagnostic service functions corresponding to the platform category from the diagnostic resource library; By utilizing the configuration difference information in the electronic and electrical architecture feature parameters, the parameters of the general diagnostic service function set are adapted to generate an effective diagnostic session for the current vehicle.

2. The automatic adaptation method for vehicle diagnostic functions according to claim 1, characterized in that, The step of responding to a diagnostic trigger command, acquiring the current vehicle's identification information, and parsing the identification information includes: Send an identity verification request to the vehicle; The vehicle receives the identification information returned by the vehicle, which includes at least one of the following: vehicle manufacturer information, vehicle model information, and production year information. The identity information is compared with records in the local identity resolution database. When a matching record is found, the corresponding resolution result and the confidence level of the resolution result are output; when no matching record is found, the resolution is deemed to have failed.

3. The automatic adaptation method for vehicle diagnostic functions according to claim 1, characterized in that, Sending the feature data acquisition request to the vehicle includes: When the dynamic adaptation mode is triggered, a set of detection commands that match the brand information or model information of the current vehicle are selected from the preset set of detection commands. According to a preset sending order, the detection commands are sequentially sent to one or more vehicle control devices of the vehicle via the vehicle bus; Set a response waiting time window, listen for the response signal returned by the vehicle control device within the response waiting time window, and receive the response signal.

4. The automatic adaptation method for vehicle diagnostic functions according to claim 1, characterized in that, The receiving vehicle obtains the response data returned by the request based on the feature data, and extracts the electronic and electrical architecture feature parameters of the vehicle based on the response data, including: The received response data is parsed to extract feature fields, which include at least one of the following categories: platform architecture identifier field, communication protocol type field, bus node distribution field, and data verification method field. The extracted feature fields are combined according to a preset data structure to generate a feature parameter set for the current vehicle. The set of feature parameters is validated to filter out invalid or abnormal feature data, thereby obtaining the standardized electronic and electrical architecture feature parameters.

5. The automatic adaptation method for vehicle diagnostic functions according to claim 1, characterized in that, The step of matching the extracted electronic and electrical architecture feature parameters with reference feature parameters in a preset platform feature information database to determine the platform category to which the vehicle belongs includes: The electronic and electrical architecture feature parameters are compared one by one with the reference feature parameters of each platform category in the preset platform feature information database, and the similarity between the electronic and electrical architecture feature parameters and each of the reference feature parameters is calculated. The calculated similarity is compared with a preset similarity threshold. When there is a platform category with a similarity greater than or equal to the preset similarity threshold, the platform category with the highest similarity is determined as the matching result. When the similarity between the electronic and electrical architecture feature parameters and all the reference feature parameters is lower than the preset similarity threshold, the matching is determined to be unsuccessful, and a security control strategy is executed.

6. The automatic adaptation method for vehicle diagnostic functions according to claim 1, characterized in that, The step of retrieving a set of general diagnostic service functions corresponding to the determined platform category from the diagnostic resource library includes: Based on the determined platform category, generate a diagnostic resource retrieval request; Send the diagnostic resource retrieval request to the diagnostic resource library, which stores the general diagnostic service function set corresponding to each platform according to platform category; The system receives a set of general diagnostic service functions that match the platform category returned by the diagnostic resource library. The set of general diagnostic service functions includes diagnostic service functions shared by various vehicle models under the platform.

7. The automatic adaptation method for vehicle diagnostic functions according to claim 1, characterized in that, The step of utilizing configuration difference information in the electronic and electrical architecture feature parameters to adapt the parameters of the general diagnostic service function set and generate a valid diagnostic session for the current vehicle includes: The configuration difference parameters of the current vehicle are parsed from the electronic and electrical architecture feature parameters. The configuration difference parameters include at least one of the following: powertrain type, drive mode, vehicle configuration option package code, and engine displacement information. Based on the configuration difference parameters, the mapping relationship of diagnostic parameters contained in the general diagnostic service function set is reconstructed to generate a diagnostic parameter configuration table adapted to the current vehicle configuration. Based on the diagnostic parameter configuration table and the communication protocol information in the electronic and electrical architecture characteristic parameters, a diagnostic communication link is established with the current vehicle, and the effective diagnostic session is generated.

8. The automatic adaptation method for vehicle diagnostic functions according to claim 1, characterized in that, The method further includes: The user-selected diagnostic operation is executed through the effective diagnostic session, and the diagnostic results are obtained; During the diagnostic process, the response to diagnostic commands is monitored. When an abnormal response or response timeout is detected, the abnormal information is recorded, and the electronic and electrical architecture characteristic parameters are corrected based on the abnormal information. The correspondence between the corrected electronic and electrical architecture feature parameters and the current vehicle's identity information is uploaded to the cloud server to update the preset platform feature information database or the identity resolution database.

9. The automatic adaptation method for vehicle diagnostic functions according to claim 1, characterized in that, The method further includes: When the confidence level of the parsing result is greater than or equal to the preset confidence threshold, the basic configuration information of the current vehicle is directly determined based on the parsing result, and the corresponding diagnostic function set is loaded using the basic configuration information; The parsing results will be used as auxiliary verification information for subsequent platform category matching.

10. An automatic adaptation device for vehicle diagnostic functions, characterized in that, include: The trigger judgment module is used to respond to the diagnostic trigger command, obtain the current vehicle's identification information, and parse the identification information; The feature acquisition module is used to trigger a dynamic adaptation mode and send a feature data acquisition request to the vehicle when the identity information parsing fails or the confidence level of the parsing result is lower than a preset confidence threshold. The feature extraction module is used to receive response data returned by the vehicle based on the feature data acquisition request, and extract the electronic and electrical architecture feature parameters of the vehicle based on the response data. The platform matching module is used to match the extracted electronic and electrical architecture feature parameters with reference feature parameters in a preset platform feature information database to determine the platform category to which the vehicle belongs. The diagnostic loading module is used to retrieve a set of general diagnostic service functions corresponding to the determined platform category from the diagnostic resource library. The session generation module is used to adapt the parameters of the general diagnostic service function set by utilizing the configuration difference information in the electronic and electrical architecture feature parameters, and generate a valid diagnostic session for the current vehicle.

Images