Vehicle diagnosis scanning method and device based on standardized diagnosis data

Abstract

The invention relates to the technical field of data processing, and discloses a vehicle diagnosis scanning method and related equipment based on standardized diagnosis data, and the method comprises the steps: obtaining the identification information of a target vehicle in response to a received diagnosis scanning instruction for the target vehicle; obtaining a standardized diagnosis data file corresponding to the target vehicle from a cloud server based on the identification information; analyzing the standardized diagnosis data file to generate an electronic control unit scanning priority set; and performing diagnosis scanning on the target vehicle according to the electronic control unit scanning priority set, sending a detection instruction according to a priority communication protocol sequence for each control unit address, determining the state of the electronic control unit according to an obtained response result, and generating a diagnosis scanning result. The vehicle diagnosis scanning efficiency can be improved, meanwhile, diagnosis errors caused by invalid operation are reduced, and the accuracy of diagnosis scanning results is guaranteed.

Description

Technical Field

[0001] This application relates to the field of data processing technology, specifically to a vehicle diagnostic scanning method and apparatus based on standardized diagnostic data. Background Technology

[0002] With the rapid development of automotive technology, vehicles are becoming increasingly electronic and intelligent, and the number of onboard electronic control units (ECUs) is constantly increasing, with their functions becoming more complex. This places higher demands on the efficiency, accuracy, and safety of vehicle diagnostic scanning technology. As a key means of diagnosing vehicle faults and ensuring the normal operation of vehicles, the core requirement of vehicle diagnostic scanning is to quickly identify the actual ECUs present in the vehicle and accurately obtain the operating status of each ECU.

[0003] Current vehicle diagnostic scanning methods typically involve pre-setting a list of all possible ECU addresses for a given vehicle model and sending probe commands to each address to complete the scan. However, since different ECUs may support different communication protocols, traditional methods require trying multiple protocols sequentially for the same ECU address to determine the effective communication method. In reality, only a small number of ECUs are installed in actual vehicles, and many of the ECUs corresponding to the pre-set addresses are not actually installed. Full address traversal leads to too many invalid probe operations, significantly increasing scan time. Furthermore, non-targeted protocol polling further increases bus load and response latency, severely impacting diagnostic scanning efficiency. Therefore, existing vehicle diagnostic scanning methods suffer from low scanning efficiency and excessive invalid operations, failing to meet the current practical needs of vehicle diagnostics for fast and efficient scanning.

[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 a vehicle diagnostic scanning method and apparatus based on standardized diagnostic data, which can improve the efficiency of vehicle diagnostic scanning, reduce diagnostic errors caused by invalid operations, and ensure the accuracy of diagnostic scanning results.

[0006] In a first aspect, embodiments of this application provide a vehicle diagnostic scanning method based on standardized diagnostic data, including: In response to receiving a diagnostic scan command for a target vehicle, the identification information of the target vehicle is obtained; Based on the identification information, a standardized diagnostic data file corresponding to the target vehicle is obtained from the cloud server. The standardized diagnostic data file includes the configuration information of the electronic control unit in the target vehicle. The standardized diagnostic data file is parsed to generate an electronic control unit (ECU) scan priority set, which includes at least one ECU address and its corresponding priority communication protocol. The target vehicle is diagnostically scanned according to the electronic control unit scan priority set. For each control unit address, a probe command is sent in order of priority communication protocol. The electronic control unit status is determined based on the obtained response results, and a diagnostic scan result is generated.

[0007] Furthermore, in some embodiments of this application, after generating the diagnostic scan results, the method further includes: The standardized diagnostic data file is updated based on the diagnostic scan results, and the updated standardized diagnostic data file is uploaded to the cloud server.

[0008] Furthermore, in some embodiments of this application, the step of obtaining the identification information of the target vehicle in response to receiving a diagnostic scan command for the target vehicle includes: The diagnostic device is connected to the self-diagnostic interface of the target vehicle, and a communication connection is established between the diagnostic device and the target vehicle. Through the communication connection, a vehicle identification code reading request is sent to the communication terminal of the target vehicle; In response to the vehicle identification code reading request, the system receives and parses the corresponding response data, and extracts the corresponding vehicle identification code as the identification information.

[0009] Furthermore, in some embodiments of this application, obtaining the standardized diagnostic data file corresponding to the target vehicle from the cloud server based on the identification information includes: The identification information is bound to the user equipment identifier, an encrypted configuration request is generated and sent to the cloud server; The cloud server queries the vehicle electronic control unit configuration archive based on the identification information and verifies the permissions of the currently requesting user. After authorization verification, the cloud server retrieves the corresponding standardized diagnostic data file from the vehicle's electronic control unit configuration archive, encrypts and digitally signs it, and generates an encrypted file. The client receives the encrypted file and performs digital signature verification. After the digital signature is verified, the encrypted file is decrypted locally to obtain the standardized diagnostic data file.

[0010] Furthermore, in some embodiments of this application, parsing the standardized diagnostic data file to generate an electronic control unit scan priority set includes: Call the local standardized diagnostic data file parsing engine to load the decrypted standardized diagnostic data file; Traverse the electronic control unit variant definition nodes in the standardized diagnostic data file to extract the logical name, physical address, and supported communication protocols of each electronic control unit; Based on preset rules or an electronic control unit protocol priority table synchronized from a cloud server, one or more priority communication protocols are determined for each electronic control unit address; The electronic control unit address and the corresponding priority communication protocol are assembled into a lightweight data structure to form the electronic control unit scan priority set.

[0011] Furthermore, in some embodiments of this application, the step of performing a diagnostic scan on the target vehicle according to the electronic control unit scan priority set, sending probe commands to each control unit address in order of priority communication protocol, determining the electronic control unit status based on the obtained response results, and generating diagnostic scan results includes: According to the address sequence in the priority set of the electronic control unit scanning, the addresses of the electronic control units to be scanned are selected in sequence; For the current electronic control unit address, diagnostic session control requests are sent sequentially according to the order of the corresponding priority communication protocol list; Listen for bus responses. If a positive response is received within a preset timeout period, the existence of the electronic control unit is determined, the corresponding communication protocol is recorded, and the process jumps to the address of the next electronic control unit. If no positive response is received within the preset timeout period, the next priority communication protocol corresponding to the current electronic control unit address will be used until all communication protocols have been tried or a positive response is received.

[0012] Furthermore, in some embodiments of this application, updating the standardized diagnostic data file based on the diagnostic scan results and uploading the updated standardized diagnostic data file to the cloud server includes: The addresses, communication protocols, and service lists of the electronic control units that successfully responded to this scan were compared with the information recorded in the historical standardized diagnostic data files. If a new electronic control unit is identified, the electronic control unit address protocol support changes, or the electronic control unit service list is updated, it is determined to be a configuration change, and a new version of the standardized diagnostic data file and update log is generated. The new version of the standardized diagnostic data file is encrypted; The encrypted new version of the standardized diagnostic data file and the update log are uploaded to the cloud server to update the vehicle electronic control unit configuration archive.

[0013] Furthermore, in some embodiments of this application, the method further includes: The cloud server continuously collects anonymized diagnostic behavior logs from multiple clients. These logs include at least one of the following: vehicle platform, model year, region, ECU address, attempted communication protocols, and successful communication protocols. The anonymized diagnostic behavior logs are aggregated and analyzed based on a combination of vehicle platform, year, region, and electronic control unit address to calculate the successful connection rate and average response time for each protocol. Based on the successful connection rate and the average response time, a protocol priority ranking is generated for each electronic control unit address under each dimension combination; The priority sorting is encapsulated into a structured electronic control unit protocol priority table, and after being version-marked, it is sent to the client.

[0014] Furthermore, in some embodiments of this application, the cloud server executes an access control policy when distributing the standardized diagnostic data file or the electronic control unit protocol priority table. The access control policy includes at least one of verifying device fingerprints, verifying user subscription permissions, setting file download limit, and setting file validity time window.

[0015] Secondly, embodiments of this application provide a vehicle diagnostic scanning device based on standardized diagnostic data, comprising: The identification acquisition module is used to acquire the identification information of the target vehicle in response to receiving a diagnostic scan command for the target vehicle; The file acquisition module is used to acquire a standardized diagnostic data file corresponding to the target vehicle from the cloud server based on the identification information. The standardized diagnostic data file includes the configuration information of the electronic control unit in the target vehicle. The file parsing module is used to parse the standardized diagnostic data file and generate an electronic control unit (ECU) scan priority set, which includes at least one ECU address and its corresponding priority communication protocol. The diagnostic scanning module is used to perform a diagnostic scan on the target vehicle according to the electronic control unit scanning priority set, send detection commands to each control unit address in order of priority communication protocol, determine the electronic control unit status based on the obtained response results, and generate diagnostic scan results.

[0016] This application provides a vehicle diagnostic scanning method and apparatus based on standardized diagnostic data. First, upon responding to a diagnostic scanning command, the target vehicle identification information is obtained, and based on this identification, a corresponding standardized diagnostic data file is retrieved from the cloud. This directly locates the basic configuration of the ECU matching the target vehicle, avoiding invalid address traversal caused by a pre-set full ECU address list in traditional methods. It also eliminates the need to send probe commands to ECU addresses not configured in the vehicle, reducing redundant operations from the source. Second, the standardized diagnostic data file is parsed to generate a scan priority set containing ECU addresses and corresponding preferred communication protocols. This clarifies the priority communication protocol order for each ECU address, prioritizing the use of protocols with higher compatibility to initiate probes, reducing protocol polling times, bus load, and response latency. Finally, probe commands are sent to the ECU addresses according to the scan priority set and the ECU status is determined based on the response. This ensures the entire scanning process revolves around the ECUs and compatible protocols that may actually exist in the target vehicle, further avoiding invalid probes and blind protocol attempts. Therefore, the vehicle diagnostic scanning scheme based on standardized diagnostic data provided in this embodiment can effectively improve the efficiency of diagnostic scanning of target vehicles, while reducing diagnostic errors caused by invalid operations and ensuring the accuracy of diagnostic scanning results. Attached Figure Description

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

[0018] Figure 1 This is an application environment diagram of the vehicle diagnostic scanning method based on standardized diagnostic data provided in the embodiments of this application; Figure 2 This is a schematic flowchart of a vehicle diagnostic scanning method based on standardized diagnostic data provided in an embodiment of this application; Figure 3 This is another schematic flowchart of the vehicle diagnostic scanning method based on standardized diagnostic data provided in the embodiments of this application; Figure 4 This is a schematic diagram of the structure of the vehicle diagnostic scanning device based on standardized diagnostic data provided in the embodiments of this application; Figure 5 This is another structural schematic diagram of the vehicle diagnostic scanning device based on standardized diagnostic data provided in the embodiments of this application; Figure 6 This is a schematic diagram of the structure of the electronic device provided in the embodiments of this application. Detailed Implementation

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

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

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

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

[0023] To address the aforementioned technical problems and overcome the shortcomings of existing technologies, this application provides a vehicle diagnostic scanning method and related equipment based on standardized diagnostic data, which can accurately determine and quickly protect fault areas in active power distribution networks, thereby improving the reliability and adaptability of differential protection in active power distribution networks.

[0024] Figure 1 This is a diagram illustrating the application environment of a vehicle diagnostic scanning method based on standardized diagnostic data in one embodiment. (Refer to...) Figure 1This vehicle diagnostic scanning method based on standardized diagnostic data is applied to a vehicle diagnostic scanning system based on standardized diagnostic data. The 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, specifically a mobile phone, tablet computer, laptop computer, or at least one of these. The server 120 can be a standalone server or a server cluster consisting of multiple servers. The server 120 is configured to execute the aforementioned vehicle diagnostic scanning method based on standardized diagnostic data, including: in response to receiving a diagnostic scanning command for a target vehicle, obtaining the target vehicle's identification information; based on the identification information, obtaining a standardized diagnostic data file corresponding to the target vehicle from a cloud server, the standardized diagnostic data file including configuration information of the electronic control units (ECUs) in the target vehicle; parsing the standardized diagnostic data file to generate an ECU scanning priority set, the ECU scanning priority set including at least one ECU address and its corresponding priority communication protocol; performing a diagnostic scan on the target vehicle according to the ECU scanning priority set, sending probe commands to each ECU address in order of priority communication protocol, determining the ECU status based on the obtained response results, and generating diagnostic scan results.

[0025] Please see Figure 2 , Figure 2 This is a flowchart illustrating a vehicle diagnostic scanning method based on standardized diagnostic data according to an embodiment of this application. This embodiment primarily uses the application of this standardized diagnostic data-based vehicle diagnostic scanning method to a server as an example for illustration. Specifically, the vehicle diagnostic scanning method based on standardized diagnostic data provided in this embodiment may include the following steps: S1. In response to receiving a diagnostic scan command for the target vehicle, obtain the identification information of the target vehicle; Specifically, in step S1, when the diagnostic device receives a diagnostic scan command for a specific target vehicle, it initiates the identification information acquisition process. This diagnostic scan command can be actively triggered by the user through the diagnostic device's operating interface, such as by clicking the "Start Diagnosis" button on the device, or it can be automatically generated by the system according to a preset diagnostic cycle. The identification information of the target vehicle is used to uniquely identify the vehicle, usually the Vehicle Identification Number (VIN), which contains key information such as the vehicle's manufacturer, model, year, and body type, ensuring accurate matching of the corresponding diagnostic data for the vehicle. For example, after the user connects the diagnostic device to a 2023 sedan via the OBD interface and clicks the "Start Scan" option on the device screen, the device receives the diagnostic scan command and then begins the operation to acquire the sedan's identification information, ultimately extracting the sedan's VIN code "LSGAR82E0HN001234".

[0026] S2. Based on the identification information, obtain the standardized diagnostic data file corresponding to the target vehicle from the cloud server. The standardized diagnostic data file includes the configuration information of the electronic control unit in the target vehicle. Specifically, in step S2, after obtaining the identification information of the target vehicle, the diagnostic device establishes a communication connection with the cloud server and sends the identification information to the cloud server. The cloud server stores a massive amount of standardized diagnostic data files corresponding to various vehicles. These standardized diagnostic data files are pre-built according to the configurations of different vehicles, and their core information includes the configuration information of each electronic control unit (ECU) in the target vehicle, such as the ECU's model, functional range, and basic data related to communication parameters. In a specific embodiment, the standardized diagnostic data file is a structured data file that conforms to the industry-unified data format standard (such as the ASAMMCD-2D / ODX 2.2.0 standard) and is specifically used to store core information related to the diagnosis of the target vehicle. Its core content revolves around the configuration information of the vehicle's electronic control units (ECUs), specifically including key data such as the logical name, physical address, supported communication protocols, supported diagnostic service list, and software version number of each ECU. Meanwhile, standardized diagnostic data files are also associated with unique vehicle identification information (such as the Vehicle Identification Number, VIN) and include auxiliary information such as vehicle model, year, and scan timestamp to ensure accurate matching with the target vehicle. Essentially, it is a standardized carrier of vehicle ECU configuration information, with the characteristics of unified format, complete information, and analyzability by diagnostic equipment. Its core purpose is to provide basic data support for vehicle diagnostic scans, enabling diagnostic equipment to quickly obtain the key configurations of the vehicle ECU, thereby generating efficient scanning strategies and avoiding ineffective probes and blind protocol attempts.

[0027] After receiving the identification information, the cloud server uses its internal retrieval mechanism to match the standardized diagnostic data file corresponding to that identification information and sends it to the diagnostic device. For example, the diagnostic device sends the obtained VIN code "LSGAR82E0HN001234" to the cloud server. The cloud server searches its database for the record corresponding to that VIN code, finds the matching standardized diagnostic data file, which records the basic configuration information of the 2023 model sedan's engine ECU, transmission ECU, body control ECU, etc., and then the cloud server transmits this file to the diagnostic device.

[0028] S3. Parse the standardized diagnostic data file to generate an electronic control unit (ECU) scan priority set, which includes at least one ECU address and its corresponding priority communication protocol. Specifically, in step S3, after receiving the standardized diagnostic data file, the diagnostic device initiates a file parsing program. During parsing, key information for each electronic control unit (ECU) is extracted from the file. The primary information obtained is the address of each ECU, which is the unique identifier for communication between the diagnostic device and the ECU. Simultaneously, based on the ECU configuration information in the file, the priority communication protocol corresponding to each ECU address is determined. This priority communication protocol is determined based on the ECU's hardware characteristics and factory settings, and is the protocol type that enables efficient communication between the diagnostic device and the ECU. Afterwards, the extracted at least one ECU address and its corresponding priority communication protocol are organized to form a structured ECU scan priority set, providing a clear execution basis for subsequent diagnostic scans. In this embodiment, the ECU scan priority set is a structured, lightweight data set generated by the diagnostic device after parsing the standardized diagnostic data file, used to guide the execution of vehicle diagnostic scans. Its core function is to clarify the target objects and communication priority order of the diagnostic scan, avoiding disordered detection and blind protocol attempts. The core components consist of two key pieces of information: first, the addresses of the Electronic Control Units (ECUs) to be scanned in the target vehicle; and second, the priority communication protocols corresponding to each ECU address, sorted by compatibility or success rate (e.g., Level 1 priority, Level 2 priority). This data set exists in a structured format for efficient reading, such as key-value pairs or lists. The ECU addresses form a fixed scanning sequence according to preset logic (e.g., functional importance, communication frequency), and the priority communication protocol associated with each address clarifies the order of attempts during scanning. Diagnostic equipment can directly access this set, scanning one address at a time according to the address sequence and initiating communication requests according to protocol priority, thereby quickly locating valid ECUs and establishing communication, providing a clear and accurate execution basis for efficient diagnostic scanning.

[0029] For example, the diagnostic equipment parses the received standardized diagnostic data file, extracts the engine ECU address "0x7E0", the transmission ECU address "0x7E1", etc., and determines that the priority communication protocol corresponding to the engine ECU is "UDSonCAN" and the priority communication protocol corresponding to the transmission ECU is "KWP2000". After organizing this information, a scan priority set is formed, which clearly lists each ECU address and its corresponding priority communication protocol.

[0030] S4. Perform a diagnostic scan on the target vehicle according to the electronic control unit scan priority set, send detection commands to each control unit address in order of priority communication protocol, determine the electronic control unit status based on the response results, and generate diagnostic scan results; Specifically, in step S4, the diagnostic equipment performs a diagnostic scan on the target vehicle based on the generated electronic control unit (ECU) scan priority set. Specifically, following the order of ECU addresses in the priority set, each ECU address to be scanned is selected sequentially. For the currently selected ECU address, a probe command is sent to the ECU strictly according to the priority communication protocol order corresponding to that address. The probe command is used to detect whether the ECU is responding normally and to obtain its basic operating status data. After sending the probe command, the diagnostic equipment monitors the ECU's response in real time. If a positive response is received from the ECU within a preset timeout period, it indicates that the ECU is in a normal, communicable state, and the relevant status information of the ECU is recorded. If no positive response is received, it is determined that the ECU may have a communication fault or abnormality. After all ECU addresses have been probed, the status information of each ECU is summarized to generate a complete diagnostic scan result. For example, the diagnostic equipment, according to the scan priority set, first selects the engine ECU address "0x7E0" and sends a probe command to it according to the priority communication protocol "UDS on CAN". If a positive response is received within the preset timeout period of 500ms, the engine ECU status is recorded as normal. Next, it selects the transmission ECU address "0x7E1" and sends a probe command according to the "KWP2000" protocol. Similarly, a positive response is received, and the transmission ECU status is recorded as normal. After all ECUs have been scanned, a diagnostic scan result containing the status of each ECU is generated.

[0031] This embodiment first obtains vehicle identification information and matches it with standardized diagnostic data from the cloud, then parses and generates an ECU scan priority set, and finally performs a precise scan according to the priority set. This process effectively avoids invalid detection of vehicles without ECUs and blind attempts to access ECU communication protocols, significantly improving the efficiency of vehicle diagnostic scanning. At the same time, it ensures accurate acquisition of the status of each ECU, guarantees the reliability of diagnostic scan results, and meets the needs of rapid and accurate vehicle diagnosis.

[0032] Furthermore, such as Figure 3 As shown, in some embodiments, after generating the diagnostic scan results, the vehicle diagnostic scan method based on standardized diagnostic data may further include: S5. Update the standardized diagnostic data file based on the diagnostic scan results, and upload the updated standardized diagnostic data file to the cloud server.

[0033] Specifically, for step S5, after generating the vehicle diagnostic scan results, this method also includes updating and uploading the standardized diagnostic data file based on the diagnostic scan results. After generating the diagnostic scan results for the target vehicle, the key information obtained during this scan is compared and analyzed with the initially used standardized diagnostic data file. In particular, it is necessary to verify core data such as the addresses of electronic control units (ECUs) successfully identified in this scan, the types of protocols that actually achieved successful communication, and the list of service functions returned by the ECUs, and determine whether there are any differences between this information and the content recorded in the initial standardized diagnostic data file. If it is found that there are new ECU addresses, changes in the communication protocols supported by existing ECUs, or updates to the ECU service function list, the initial standardized diagnostic data file is modified and improved based on the scan results to ensure that the updated file accurately reflects the actual configuration status of the current vehicle ECUs.

[0034] After updating the standardized diagnostic data file, the updated file is transmitted to the cloud server via a secure communication link between the diagnostic device and the cloud server. During the upload process, the integrity and security of the file transmission must be ensured to prevent data loss or tampering. Upon receiving the updated file, the cloud server locates the historical data storage location for the vehicle based on its identification information (such as the Vehicle Identification Number, VIN), replaces the original file with the updated one, and synchronously updates the standardized diagnostic data file for that vehicle on the cloud server. This provides the latest and most accurate data support for subsequent diagnostic scans of the vehicle.

[0035] This embodiment updates standardized diagnostic data files based on diagnostic scan results and uploads them to a cloud server. This ensures that the vehicle diagnostic data stored in the cloud can match the actual configuration changes of the vehicle's ECU in real time, providing an accurate data foundation for subsequent diagnostic scans of the vehicle. At the same time, it enables dynamic iteration and long-term effective management of vehicle diagnostic data, improving the timeliness and availability of diagnostic data.

[0036] Furthermore, in some embodiments, step S1, "in response to receiving a diagnostic scan command for the target vehicle, obtaining the identification information of the target vehicle," may specifically include: S11. Connect the diagnostic equipment to the self-diagnostic interface of the target vehicle and establish a communication connection between the diagnostic equipment and the target vehicle; Specifically, for step S11, when it is necessary to obtain the identification information of the target vehicle, the diagnostic device's connection cable (such as an OBD diagnostic cable) is first physically connected to the target vehicle's self-diagnostic interface. The self-diagnostic interface is usually located under the steering wheel or near the center console in the vehicle's cockpit and conforms to industry-standard interfaces such as OBD-II. After the physical connection is completed, the diagnostic device will automatically initiate the communication initialization process, establishing a stable bidirectional data communication connection with the target vehicle's on-board diagnostic system by sending handshake signals and negotiating communication parameters (such as baud rate, data bits, stop bits, etc.), ensuring that subsequent data commands and response information can be transmitted normally.

[0037] S12. Send a vehicle identification code reading request to the target vehicle's communication terminal via the communication connection; Specifically, in step S12, after the diagnostic device establishes a stable communication connection with the target vehicle, the diagnostic device generates a Vehicle Identification Number (VIN) read request command that conforms to vehicle diagnostic protocol specifications (such as UDS, KWP2000, etc.). This command contains a clear request type identifier (i.e., read VIN). The diagnostic device sends this read request command to the target vehicle's communication terminal through the established communication connection, typically the vehicle's gateway ECU or an ECU specifically responsible for diagnostic information exchange, triggering the vehicle's internal VIN information retrieval process.

[0038] S13. Respond to the vehicle identification code reading request, receive and parse the corresponding response data, and extract the corresponding vehicle identification code as identification information; Specifically, in step S13, after the target vehicle's communication terminal (such as the gateway ECU) receives the VIN read request sent by the diagnostic device, it verifies the legality of the request, such as whether the request format is correct and whether it meets communication permissions. After successful verification, it retrieves the corresponding VIN data from the vehicle's internal storage (such as the ECU's EEPROM) and generates response data containing VIN information according to the communication protocol format negotiated with the diagnostic device. This response data is then fed back to the diagnostic device via the communication connection. After receiving the response data, the diagnostic device starts a data parsing program to remove redundant information such as protocol headers and check bits from the response data and extracts the core VIN string. This VIN string is the unique identification information used to identify the target vehicle.

[0039] The standardized process described in this embodiment can reliably and accurately obtain the unique identification information of the target vehicle, providing a reliable identity basis for subsequent matching of standardized diagnostic data files in the cloud. At the same time, it ensures the standardization and compatibility of the identification information acquisition process and is applicable to the self-diagnostic interfaces and communication protocols of different vehicle models.

[0040] Furthermore, in some embodiments, step S2, "based on the identification information, obtaining the standardized diagnostic data file corresponding to the target vehicle from the cloud server," may specifically include: S21. Bind the identification information to the user equipment identifier, generate an encrypted configuration request, and send it to the cloud server; Specifically, for step S21, firstly, the identification information of the target vehicle (such as the Vehicle Identification Number, VIN) and the unique identifier of the currently used diagnostic equipment, i.e., the User Equipment Identifier, are obtained. This identifier may include the device hardware serial number, device MAC address, etc., used to distinguish different diagnostic equipment. Through preset binding rules, the vehicle identification information and the User Equipment Identifier are associated and integrated to form basic request data containing a "vehicle identity - device identity" correspondence. Subsequently, the basic request data is encrypted using an encryption algorithm (such as AES, RSA, etc.) to generate an encrypted configuration request that is tamper-proof and leak-proof. Finally, the diagnostic equipment sends this encrypted configuration request to the cloud server via a network (such as 4G, WiFi), initiating a request to obtain standardized diagnostic data files.

[0041] S22. Query the vehicle electronic control unit configuration archive based on the identification information via the cloud server, and verify the permissions of the currently requesting user; Specifically, in step S22, after receiving the encrypted configuration request, the cloud server first decrypts the request data using the corresponding decryption algorithm to extract the vehicle identification information and the user device identifier. On one hand, the cloud server uses the vehicle identification information as a search keyword to query a pre-established vehicle electronic control unit (ECU) configuration archive. This archive is categorized by vehicle identification information, with each category storing the corresponding standardized diagnostic data file for that vehicle, thus locating the standardized diagnostic data file that may match the target vehicle. On the other hand, based on the extracted user device identifier, the cloud server retrieves user permission data stored in the background, such as the range of vehicles the device is authorized to access and the data acquisition permission level, to verify whether the user initiating the request (associated with the device identifier) ​​has the permission to obtain the standardized diagnostic data file of the target vehicle, such as whether the device is bound to the vehicle and whether it is within the authorization validity period.

[0042] S23. After passing the authorization verification, retrieve the corresponding standardized diagnostic data file from the vehicle's electronic control unit configuration archive via the cloud server, encrypt and digitally sign it, and generate an encrypted file; Specifically, in step S23, after the cloud server completes the permission verification and confirms that the user has access rights, it retrieves the standardized diagnostic data file that perfectly matches the target vehicle from the vehicle ECU configuration archive. To ensure the security and integrity of the file transfer process, the cloud server first encrypts the retrieved standardized diagnostic data file using an encryption algorithm (which can be consistent with or compatible with the aforementioned encryption algorithm) to prevent the file content from being stolen. Next, the cloud server uses its own proprietary digital certificate (containing a private key) to digitally sign the encrypted file. The digital signing process generates unique signature information, which is bound to the file content and can be used to verify whether the file has been tampered with. Finally, the encrypted file and the corresponding digital signature are integrated to form a complete encrypted file.

[0043] S24. After receiving the encrypted file through the client, perform digital signature verification; Specifically, in step S24, after the diagnostic device (i.e., the client) receives the encrypted file sent by the cloud server via the network, it first extracts the digital signature information contained in the encrypted file. Subsequently, the client calls the preset signature verification module and uses the cloud server's public key (which is pre-stored on the client and matches the server's private key) to verify the extracted digital signature. The verification process compares the matching of the digital signature with the content of the encrypted file. If they match, it means that the encrypted file has not been tampered with during transmission and does indeed come from a legitimate cloud server, and the signature verification passes; if they do not match, it is determined that the file may have been tampered with or has an illegal source, and subsequent decryption operations are rejected.

[0044] S25. After digital signature verification, the encrypted file is decrypted locally to obtain a standardized diagnostic data file; Specifically, for step S25, after the client completes and successfully verifies the digital signature, the local decryption process is initiated. The client calls the decryption module corresponding to the encryption algorithm of the cloud server, inputs a preset decryption key, which matches the key used for cloud encryption and can be pre-configured on the client through user authorization, device binding, etc., to decrypt the encrypted file. After decryption, the originally encrypted standardized diagnostic data file is restored to its readable and parsable original format, and the client can then obtain the standardized diagnostic data file corresponding to the target vehicle, providing a data foundation for the subsequent generation of the ECU scan priority set.

[0045] This embodiment employs a comprehensive security design to accurately locate and acquire standardized diagnostic data files for the target vehicle, while ensuring the security and integrity of data transmission and storage to prevent data leakage or tampering. Furthermore, it uses permission verification to ensure the legitimacy of data access, providing reliable and secure data support for subsequent diagnostic scans.

[0046] Furthermore, in some embodiments, step S3, "parse the standardized diagnostic data file to generate an electronic control unit scan priority set," may specifically include: S31. Call the local standardized diagnostic data file parsing engine to load the decrypted standardized diagnostic data file; Specifically, in step S31, after obtaining the decrypted standardized diagnostic data file, the diagnostic device will activate its locally preset standardized diagnostic data file parsing engine. This parsing engine is a program module specifically designed for the standardized diagnostic data file format, capable of recognizing file structure and reading data fields. Subsequently, the parsing engine locates the decrypted standardized diagnostic data file through the file path, loads the file data into the diagnostic device's memory, and prepares for subsequent data extraction and parsing, ensuring that the file data can be read and processed normally by the parsing engine.

[0047] In this embodiment, the workflow of the local standardized diagnostic data file parsing engine is as follows: First, it receives the decrypted standardized diagnostic data file and verifies its legality and compatibility using preset file format recognition rules. This includes verifying key information such as the file header identifier, format version number, and data check bits to ensure the file is not corrupted and conforms to the standards supported by the engine, avoiding parsing failures due to file format errors. After successful verification, the file data is loaded into the diagnostic device's memory buffer, providing a data foundation for subsequent parsing. The standardized diagnostic data file stores information in a fixed structure. Based on the corresponding industry standards and preset node parsing rules, the engine quickly locates the core data areas in the file, focusing on Electronic Control Unit (ECU) variant definition nodes. These nodes are structured units that specifically record the configuration information of a single ECU, with each node corresponding to an ECU instance in a vehicle. The engine automatically traverses all nodes of this type in the file to ensure that no ECU configuration data is missed. For each identified ECU variant definition node, the engine extracts key information required for diagnostic scanning based on the field definitions within the node: It extracts the ECU's functional identifier from the node's logical name field; it extracts the ECU's physical address from the communication parameter sub-node, which is the unique identifier for communication between the diagnostic device and the ECU; and it extracts all communication protocols supported by the ECU from the protocol configuration field, clarifying the ECU's communication compatibility range. During extraction, the engine automatically filters redundant fields in the node (such as comments and reserved configuration bits), retaining only the core information directly related to the diagnostic scan. The scattered information extracted from all ECU nodes is integrated into a unified lightweight data format (such as key-value pairs and lists), using the ECU physical address as the core index, and associating it with the corresponding logical name, supported communication protocols, and other information to form a structured intermediate data set. This intermediate data set can be directly called by subsequent modules to generate the electronic control unit scan priority set.

[0048] S32. Traverse the electronic control unit variant definition nodes in the standardized diagnostic data file to extract the logical name, physical address, and supported communication protocols of each electronic control unit; Specifically, in step S32, after the parsing engine loads the file, it locates the Electronic Control Unit (ECU) variant definition node according to the preset structure of the standardized diagnostic data file. This node is the core area in the file that specifically records the configuration information of each ECU, and each node corresponds to a variant configuration of one ECU. The parsing engine will traverse all ECU variant definition nodes one by one, and extract three key pieces of information from each node: first, the logical name of the ECU, used to identify the function of the ECU, such as "engine control module" or "transmission control module"; second, the physical address of the ECU, used for the hardware address for communication between the diagnostic device and the ECU, such as "0x7E0" or "0x7E1"; and third, the communication protocol supported by the ECU, such as "UDSonCAN", "KWP2000", or "DoIP", ensuring that the core configuration information of each ECU is completely extracted.

[0049] S33. Determine one or more priority communication protocols for each electronic control unit address according to preset rules or electronic control unit protocol priority table synchronized from cloud server; Specifically, for step S33, after extracting the physical addresses and supported communication protocols of each ECU, a preferred communication protocol needs to be determined for each ECU address. There are two methods for this determination: the first is based on rules pre-set locally on the diagnostic equipment, such as sorting by protocol universality and prioritizing mainstream industry protocols; the second is based on an electronic control unit protocol priority table synchronized from the cloud server to the local machine. This table is generated based on diagnostic data from a large number of vehicle models and clarifies the protocol usage priority corresponding to different ECU addresses. Using either of these methods, the multiple supported protocols corresponding to each ECU physical address are prioritized, and one or more preferred communication protocols are determined (arranged from highest to lowest priority).

[0050] In this embodiment, the Electronic Control Unit (ECU) protocol priority table is a structured data table generated by a cloud server based on massive anonymized diagnostic behavior logs after aggregation and analysis. Its purpose is to provide diagnostic equipment with the optimal attempt order of ECU communication protocols under different scenarios, avoiding blind protocol polling and improving diagnostic scanning efficiency. The table is divided into dimensions based on "vehicle platform-year-region-ECU address," with each dimension corresponding to an independent protocol priority rule, ensuring that the priority adapts to specific vehicle scenarios and covers the different needs of different vehicle models, production years, and usage regions. The sorting is based primarily on "successful connection rate" (the proportion of successful communication attempts out of the total number of attempts), with average response time as a secondary indicator (the average command response time during successful communication). Protocols with high successful connection rates and short response times are given higher priority. The table is dynamically updated with continuously collected diagnostic logs from the cloud, periodically aggregating new data to recalculate protocol performance indicators, and iterating versions before being distributed to the client to ensure that the priority order always adapts to the actual diagnostic scenario.

[0051] S34. Assemble the electronic control unit address and the corresponding priority communication protocol into a lightweight data structure to form an electronic control unit scan priority set; Specifically, in step S34, after matching each ECU address with its preferred communication protocol, the diagnostic equipment assembles the two using a preset lightweight data structure (such as key-value pairs, lists, etc.). The key of this data structure is the ECU's physical address, and the value is a list of preferred communication protocols corresponding to that address (sorted by priority). The assembly results of all ECU addresses and their corresponding preferred communication protocols are integrated to form a complete electronic control unit scan priority set. This priority set can be directly used for subsequent scanning operations of the vehicle's ECUs by the diagnostic equipment.

[0052] This embodiment extracts key information from the ECU using a dedicated parsing engine, determines protocol priorities according to rules, and assembles a lightweight priority set. This can quickly transform standardized diagnostic data files into structured data that can be directly used for scanning, clarifying the scanning order and communication priority of each ECU. This provides a clear and accurate execution basis for subsequent efficient diagnostic scanning, while reducing redundant data parsing operations and effectively improving the efficiency of the diagnostic preparation stage.

[0053] Furthermore, in some embodiments, step S4, "performing a diagnostic scan of the target vehicle according to the electronic control unit scan priority set, sending probe commands to each control unit address in order of priority communication protocol, determining the electronic control unit status based on the obtained response results, and generating diagnostic scan results," may specifically include: S41. Select the addresses of the electronic control units to be scanned in sequence according to the address sequence in the priority set of electronic control unit scanning; Specifically, in step S41, the diagnostic device first reads the generated electronic control unit (ECU) scan priority set, which contains a sequence of ECU addresses arranged according to preset logic, such as sorting by ECU functional importance or communication frequency. Subsequently, the diagnostic device selects the ECU address to be scanned one by one according to the order of the address sequence, ensuring that the scanning process follows the order set in the priority set, and avoiding inefficiency or omission of critical ECUs caused by disordered scanning.

[0054] S42. For the current electronic control unit address, send diagnostic session control requests sequentially according to the order of the corresponding priority communication protocol list; Specifically, in step S42, for the currently selected ECU address, the diagnostic device retrieves the priority communication protocol list corresponding to that address from the scan priority set. The protocols in the list are arranged from highest to lowest priority. Subsequently, the diagnostic device generates diagnostic session control requests conforming to the diagnostic specifications using the corresponding protocols in sequence according to the protocol list. These requests are used to initiate diagnostic communication with the ECU and verify whether the ECU can respond normally. Only one protocol is used to send the request at a time. After the current protocol request completes its response assessment, the request for the next priority protocol is sent.

[0055] S43. Monitor bus response. If a positive response is received within the preset timeout period, determine that the electronic control unit exists, record the corresponding communication protocol, and jump to the address of the next electronic control unit. Specifically, in step S43, after the diagnostic device sends the diagnostic session control request, it immediately starts the bus monitoring program to receive the response data transmitted by the vehicle bus in real time, and simultaneously starts timing. The timing duration is a preset timeout period, such as 500ms or 1000ms, set according to protocol characteristics or vehicle type. If the diagnostic device receives a positive response from the current ECU before the timing ends, such as a "0x50" response under the UDS protocol or a "0xC1" response under the KWP2000 protocol, it determines that the ECU corresponding to that address actually exists and communication is normal, and records the protocol type used for this successful communication; then it stops scanning the current ECU address and automatically jumps to the next ECU address in the scan priority set, repeating the operations of steps S42-S43.

[0056] S44. If no positive response is received within the preset timeout period, the next priority communication protocol corresponding to the current electronic control unit address shall be used until all communication protocols have been tried or a positive response is received. Specifically, for step S44, if the diagnostic device does not receive a positive response corresponding to the current protocol within the preset timeout period, including situations such as receiving no response or receiving a negative response, it is determined that the current protocol cannot establish effective communication with the ECU. At this time, the diagnostic device will check the priority communication protocol list corresponding to the current ECU address to see if there is any untried next priority protocol: if so, it will immediately switch to the next priority protocol and repeat the request sending and response listening operation of steps S42-S43; if all protocols have been tried and no positive response is received, it is determined that the ECU corresponding to the address does not exist or has a communication failure, the result is recorded, and then it jumps to the next ECU address.

[0057] This embodiment can quickly locate existing ECUs and determine valid communication protocols by scanning ECU addresses in priority set order and sending requests according to protocol priority and judging responses in real time. This avoids scanning invalid addresses and blindly trying low-priority protocols, greatly reducing the time consumption and bus load of diagnostic scanning. At the same time, it accurately judges the existence status of ECUs and ensures the accuracy of diagnostic scanning results.

[0058] Furthermore, in some embodiments, step S5, "updating the standardized diagnostic data file based on the diagnostic scan results and uploading the updated standardized diagnostic data file to the cloud server," may specifically include: S51. Compare the electronic control unit address, communication protocol, and service list of the successfully responded electronic control unit with the information recorded in the historical standardized diagnostic data file; Specifically, for step S51, after generating the diagnostic scan results for the target vehicle, key information is first extracted from the scan results, including: the physical addresses of the electronic control units (ECUs) that successfully responded in this scan, the communication protocols used to successfully communicate with each ECU, and the list of support services returned by each ECU, such as service IDs like "0x10 Diagnostic Session Control" and "0x22 Read Data Identifier" under the UDS protocol. Then, the historical standardized diagnostic data file used for this scan is retrieved, i.e., the old version of the vehicle's diagnostic data file obtained from the cloud or stored locally before the scan. The key information extracted this time is compared one by one with the corresponding information recorded in the historical file to check for any discrepancies.

[0059] S52. If a new electronic control unit is identified, the electronic control unit address protocol support changes, or the electronic control unit service list is updated, it is determined to be a configuration change, and a new version of the standardized diagnostic data file and update log are generated. Specifically, for step S52, based on the comparison in step S51, the differences are determined. If the difference is any one or more of the following: "Added ECU (i.e., an ECU not recorded in the historical file but present in this scan)," "Change in the communication protocol supported by the original ECU (e.g., a historical file records that an ECU only supports KWP2000, but this scan finds that it also supports UDSonCAN)," or "Update to the service list of the original ECU (e.g., adding or deleting supported service IDs)," then it is determined that the vehicle's ECU configuration has changed. At this time, based on the scan results, the historical standardized diagnostic data file is modified, such as adding configuration information for the newly added ECU, updating the protocol and service list, and generating a new version of the standardized diagnostic data file containing the latest configuration. At the same time, an update log is generated, recording the configuration changes in detail, such as "Added ADASECU, address 0x7E0, protocol DoIP," update time, scanning device identifier, etc., for easy traceability later.

[0060] S53. Encrypt the new version of the standardized diagnostic data file; Specifically, for step S53, to ensure the security of the new version standardized diagnostic data file during transmission and storage, and to prevent data theft or tampering, it needs to be encrypted. The encryption process uses a preset encryption algorithm (such as AES, RSA, etc.) and a key agreed upon with the cloud server (such as the device-bound exclusive key or the user authorization key) to encrypt the new version file, generating an encrypted file that ensures only authorized parties (such as the corresponding cloud server) can decrypt and read the file content.

[0061] S54. Upload the encrypted new version of the standardized diagnostic data file and update log to the cloud server to update the vehicle electronic control unit configuration archive; Specifically, in step S54, after encryption, the diagnostic device sends the encrypted new version of the standardized diagnostic data file and update log to the cloud server via a secure network channel (such as WiFi, 4G / 5G). Upon receiving the file and log, the cloud server locates the corresponding historical data storage location for the vehicle in the vehicle ECU configuration archive based on the target vehicle's unique identification information (such as the VIN code). It then replaces the original old file with the encrypted new version file and associates the update log with the vehicle's historical logs, completing the synchronized update of the archive and ensuring that subsequent diagnostic scans of the vehicle can access the latest configuration data.

[0062] This embodiment compares the scan results with historical data to identify configuration changes, generates a new version file, and uploads it in encryption. This ensures that the vehicle diagnostic data stored in the cloud is consistent with the actual configuration of the vehicle's ECU, achieving dynamic updates and accurate synchronization of diagnostic data. This provides the latest data support for subsequent diagnostic scans of the vehicle, while also ensuring the security and traceability of the data update process.

[0063] Furthermore, in some embodiments, the method may further include dynamically generating and sending electronic control unit protocol priorities to the client based on multi-source diagnostic data, with the specific steps as follows: S61. Continuously collect anonymized diagnostic behavior logs from multiple clients via a cloud server. The anonymized diagnostic behavior logs include at least one of the following: vehicle platform, model year, region, ECU address, attempted communication protocols, and successful communication protocols. Specifically, for step S61, the cloud server continuously receives and stores anonymized diagnostic behavior logs uploaded from different clients (i.e., various diagnostic devices) through a preset communication interface. These clients cover different regions and different types of diagnostic scenarios. The uploaded logs have removed sensitive data such as vehicle VIN codes and user identity information, retaining only core non-identifying information related to the diagnosis, including but not limited to: the target vehicle's model platform (e.g., "F30" or "MEB"), production year (e.g., "2022" or "2023"), usage region (e.g., "EU", "CN", or "NA"), electronic control unit (ECU) physical address (e.g., "0x7E0" or "0x760"), communication protocols attempted during the diagnostic process (e.g., "UDS on CAN", "KWP2000", or "DoIP"), and the type of protocol that ultimately established successful communication. Log uploads can be triggered in real time after the client completes the diagnosis, or uploaded in batches according to a preset period (e.g., daily), ensuring that the cloud can continuously accumulate massive amounts of diagnostic behavior data.

[0064] S62. Aggregate and analyze the anonymized diagnostic behavior logs by combining vehicle platform, year, region, and electronic control unit address, and calculate the successful connection rate and average response time for each protocol; Specifically, in step S62, the cloud server starts the log analysis program. First, it groups and aggregates the massive amount of anonymized logs according to the combined dimensions of "vehicle platform-year-region-ECU address," grouping logs under the same combined dimension together to ensure the analysis results accurately match specific scenarios. For example, "F30 platform-2023 model-EU region-0x7E0 address" is a separate group. For the logs within each group, the following two core metrics are calculated: first, the successful connection rate, which is the proportion of times a certain communication protocol successfully establishes communication within the group to the total number of attempts to use that protocol within the group; second, the average response time, which is the average time from sending a probe command to receiving a positive response when successfully communicating using a certain protocol within the group, excluding timeout or failure records. These two metrics quantify the adaptability and efficiency of different protocols in specific scenarios.

[0065] In a specific implementation, the aggregation analysis process is as follows: First, the collected raw anonymized diagnostic behavior logs are preprocessed to ensure data quality. The first step is format standardization, unifying field names and data formats for logs uploaded from different clients. The second step is data cleaning, removing invalid logs and outliers to prevent such data from affecting the accuracy of the analysis results. Finally, the processed logs are stored in a distributed data warehouse to provide a standardized data source for subsequent analysis. After preprocessing, the standardized logs are grouped and aggregated according to a fixed combination dimension of "vehicle platform-year-region-ECU address". The cloud server, through a distributed computing framework, traverses all logs, grouping logs with the same vehicle platform, year, region, and ECU address into an independent analysis group. This ensures that the logs in each group correspond to the same specific application scenario, achieving precise scenario-based analysis and avoiding result bias caused by the mixing of logs from different scenarios. For each independent analysis group, two core performance indicators were calculated to quantify the adaptation effect of each communication protocol. For the successful connection rate, the attempted and successful protocols for each log entry within the group were statistically analyzed. For the same protocol, the total number of attempts, the total number of successful communication establishments, and the successful connection rate were accumulated. For the average response time, all logs of successful communication for a specific protocol within the group were selected, and the response time field of each log entry was extracted, removing extreme outliers. After the indicators were calculated, the results for each analysis group were verified. First, sample size verification: if the number of attempts for a certain protocol within a group was too low, the sample size was deemed insufficient, and the indicator results for that protocol were temporarily not used until subsequent logs were accumulated and recalculated. Second, consistency verification: the indicators were compared with those of similar groups of the same vehicle platform, adjacent model years, or the same region. If the indicators of a group differed significantly from those of similar groups, the logs of that group were backtracked to check for data anomalies, and if necessary, the logs were cleaned and recalculated. After successful verification, the indicator results for that group were retained. After all analysis groups completed the calculation and verification of the indicators, the core information of each group was summarized in a unified structured format to form a dataset of the correspondence between scenario, protocol and performance, which provides direct data support for the subsequent generation of electronic control unit protocol priority ranking.

[0066] S63. Generate a protocol priority ranking for each electronic control unit address under each dimension combination based on the successful connection rate and average response time; Specifically, for step S63, for each obtained "vehicle platform-year-region-ECU address" combination group, the cloud server prioritizes the success rate as the primary sorting criterion; the higher the success rate, the higher the priority. The average response time is used as a secondary sorting criterion; when success rates are the same, the shorter the average response time, the higher the priority. All communication protocols involved within this group are then prioritized. The sorting result establishes the protocol usage priority order for this ECU address under a specific combination dimension, clarifying the protocol types that should be tried first during diagnosis.

[0067] S64. Encapsulate the priority sorting into a structured electronic control unit protocol priority table, and send it to the client after version marking; Specifically, in step S64, the cloud server sorts the protocol priorities of ECU addresses under all combined dimensions, integrates and encapsulates them according to a preset structured format (such as JSON or XML), forming a complete electronic control unit protocol priority table. This table clearly marks the protocol priority order corresponding to each "vehicle platform-year-region-ECU address" combination, and adds a version marker to the table, such as "20241020.V1," including the generation date and version number, to facilitate client identification of update iterations. After encapsulation and version marking are completed, the cloud server proactively sends the priority table to all clients through a secure communication channel; or, when a client initiates an update request, pushes the latest version of the priority table to the client, ensuring that the client can obtain the latest protocol priority guidance data.

[0068] This embodiment collects anonymous logs from multiple clients and aggregates and analyzes protocol performance by scenario. Finally, it generates and distributes a structured priority table, which allows clients to obtain the optimal protocol usage order that is suitable for different vehicle models, years, and regions. This reduces blind protocol attempts during diagnosis and improves scanning efficiency. At the same time, the priority table is dynamically updated with actual diagnostic data to ensure continuous optimization of compatibility.

[0069] Furthermore, in some embodiments, the cloud server executes an access control policy when distributing standardized diagnostic data files or electronic control unit protocol priority tables. The access control policy includes at least one of verifying device fingerprints, verifying user subscription permissions, setting file download limit, and setting file validity time window.

[0070] Specifically, the access control policy executed by the cloud server when distributing standardized diagnostic data files or electronic control unit protocol priority tables is implemented through at least one of the following policies.

[0071] (1) Verify device fingerprint.

[0072] When a client (such as a diagnostic device) sends a request to the cloud server for a file (standardized diagnostic data file or electronic control unit protocol priority table), it automatically generates and carries its own device fingerprint. The device fingerprint is a unique string generated using a preset algorithm (such as a hash algorithm) based on the diagnostic device's unique hardware identifier (such as hardware serial number, CPU model, MAC address) or software characteristics (such as system version, proprietary certificate), used to identify the device's legitimacy. Upon receiving the request, the cloud server extracts the device fingerprint and retrieves a pre-stored "device-fingerprint binding database." This database records the legitimate fingerprint information of authorized diagnostic devices, typically entered when the device is first registered or bound to a user. The cloud server compares the device fingerprint in the request with the legitimate fingerprints in the binding database: if they match perfectly, the device is deemed legitimate, and the file delivery process continues; if the fingerprint does not match or no corresponding record is found in the binding database, the device is deemed illegitimate, the file delivery request is rejected, and the client is notified of an "unauthorized device" message.

[0073] (2) Verify user subscription permissions.

[0074] When a client initiates a file retrieval request, it needs to associate user account information (such as the user's login token and account ID). This account information is sent to the cloud server along with the request. The cloud server, based on the user account information, retrieves the "User-Subscription Permission Database" from the backend. This database records the scope of subscription permissions that each user account has purchased or activated, including accessible vehicle platforms (such as "F30 platform" and "MEB platform"), file types (such as "2022-2024 Standardized Diagnostic Data Files" and "EU Region ECU Protocol Priority Table"), and permission validity period. The cloud server compares the currently requested file information (such as the vehicle model, region, and type corresponding to the file) with the user's subscription permission scope: if the file is within the subscription permission coverage and the permission has not expired, the user is deemed entitled to obtain the file, and the file delivery process continues; if the file is outside the subscription scope or the permission has expired, the user is deemed not authorized, the delivery is rejected, and a "Insufficient Subscription Permissions" message is displayed.

[0075] (3) Set a limit on the number of times a file can be downloaded.

[0076] When the cloud server generates files to be distributed (standardized diagnostic data files or ECU protocol priority tables), it presets download limits based on the file's association with a specific user / device. For example, it might specify that "for user A's device 1, this file can only be downloaded once," or "for a certain batch of files, all authorized devices can download it 3 times." The cloud server stores the mapping between "file identifier - user / device identifier - remaining download count" in a download count management database. When a client initiates a file download request and passes prior permission verification (such as device fingerprint or subscription permission verification), the cloud server queries the download count management database to obtain the remaining download count for that client. If the remaining download count is greater than 0, the cloud server allows the download, decrements the remaining count by 1, and updates the management database. If the remaining download count is 0, it determines that the download count has been exhausted, refuses further downloads, and displays a "File has reached maximum download count" message.

[0077] (4) Set the file validity period window.

[0078] Before distributing a file, the cloud server attaches a valid time window attribute to it, which is a preset valid start and end time (e.g., "2024-10-20 00:00:00 to 2024-10-27 23:59:59"). This time information is embedded in the file header or distributed as independent metadata along with the file. After receiving the file, the client automatically reads the file's valid time window information and compares it with the current system time before using it (e.g., parsing the file, performing diagnostic scans based on the file). If the current time is within the valid time window, the file is considered valid and can be used normally; if the current time is earlier than the start time or later than the end time, the file is considered expired, its use is prohibited, and a message "File expired, please re-acquire" is displayed. The cloud server synchronously records the valid time window for each file. If the client initiates a re-acquisition request after a file expires, the cloud server will regenerate the file with the new valid time window and distribute it, requiring permission verification again.

[0079] This embodiment employs at least one access control strategy, such as device fingerprint verification, user subscription permission verification, download limit, and effective time window, to strictly control the distribution scope and usage specifications of standardized diagnostic data files and ECU protocol priority tables. This prevents files from being obtained by unauthorized devices, used beyond authorized permissions, repeatedly abused, or used for extended periods without authorization, thus comprehensively ensuring the security and compliance of the data distribution process.

[0080] To facilitate understanding of the vehicle diagnostic scanning method based on standardized diagnostic data provided in this embodiment, this embodiment will be described in detail with specific examples.

[0081] Step 1: Initial Scan and ODX Data Generation.

[0082] When diagnostic equipment is first connected to a vehicle: 1.1. Read the vehicle VIN code.

[0083] 1.2. Traverse the preset ECU address list and use various protocols (KWP2000, UDS on CAN, DoIP, etc.) to detect responses.

[0084] 1.3. Record the actual ECU response information, including: ECU physical address (Address); Communication protocol type (Protocol); Supported service IDs (e.g., 0x10, 0x22); Software version number (SW Version).

[0085] 1.4. The above information is structured and packaged into a data file (.odx or .pdx) conforming to the ASAM MCD-2D / ODX 2.2.0 standard, and labeled with VIN, vehicle model, model year, and scan timestamp.

[0086] Step 2: ODX data encryption upload and cloud archiving.

[0087] 2.1. Upload the generated ODX file to the cloud server after AES encryption; 2.2. The server establishes a "Vehicle-ECU Configuration Archive" using the VIN as the unique index. 2.3. Simultaneously, an "ECU-protocol statistical model" is established based on vehicle platform, model year, and region to generate a protocol priority table.

[0088] Step 3: Historical data matching and configuration distribution during the rescan.

[0089] 3.1 When the user reconnects to the vehicle: The app or device reads the VIN, or the user selects the vehicle model. Send a request to the cloud: "Retrieve the ODX configuration file for this VIN or vehicle model"; After the server verifies the user's permissions, it sends the corresponding ODX file to the client. The client parses the ODX file, extracts the list of ECUs as the "priority set for this scan", and skips the addresses of ECUs that do not respond.

[0090] Step 4: Priority-based protocol scheduling strategy.

[0091] 4.1. Synchronize the "ECU-Protocol Priority Table" from the cloud: For example: The BMW F30 gateway (0x7E0) uses UDS with a 98% probability, while KWP only uses it with a 2% probability → UDS should be tried first; Priority is dynamically updated based on vehicle platform, model year, and sales region; 4.2. During scanning, probe commands are sent to each target ECU address in priority order to avoid invalid polling.

[0092] Step 5: Adaptive learning and ODX update.

[0093] 5.1. Comparison of the current scan results with historical ODX data: If a new ECU is found (such as an ADAS module), update the ODX file; If the protocol response changes (e.g., ECU upgrade to support DoIP), then update the protocol priority; 5.2. The updated ODX file is re-encrypted and uploaded to achieve closed-loop learning.

[0094] Step Six: Security Control Mechanism.

[0095] 6.1. User authentication (account / authorization code) is required before ODX files are distributed; 6.2. Files are linked to device fingerprints or user accounts to prevent unauthorized distribution; 6.3. Supports digital rights protection strategies such as "download only once" and "valid for a limited time".

[0096] Taking "users using the app to perform a quick scan on a BMW F30 320Li" as an example: 1. The user opens the APP and connects the OBD device; 2. The APP reads the VIN: WBA**FEP0*XXXXXXX; 3. Request the ODX configuration file for the VIN from the cloud; 4. The server returns the 7 recorded ECUs (engine, gateway, instrument cluster, etc.); 5. The app parses the ODX and only probes these 7 addresses; 6. For each ECU, send the protocol according to priority: Gateway (0x700): First send UDS (successful), then do not attempt KWP. Engine (0x7E0): First try UDS (failed), then try KWP (successful). 7. Scan complete, taking 13 seconds (68 seconds for the first scan); 8. If a new HUD module is detected, update the ODX file and upload it.

[0097] In summary, the vehicle diagnostic scanning method based on standardized diagnostic data provided in this embodiment first obtains a standardized diagnostic data file containing ECU configuration information from the cloud based on the target vehicle identification information, then parses and generates a scan priority set containing ECU addresses and corresponding priority communication protocols, and finally sends probe commands to the ECU addresses according to the priority communication protocol order and determines the ECU status. This effectively improves the efficiency of diagnostic scanning of the target vehicle, while reducing diagnostic errors caused by invalid operations and ensuring the accuracy of the diagnostic scanning results.

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

[0099] To facilitate better implementation of the vehicle diagnostic scanning method based on standardized diagnostic data according to the embodiments of this application, this application also provides a vehicle diagnostic scanning device based on standardized diagnostic data, which is based on the aforementioned vehicle diagnostic scanning method based on standardized diagnostic data. The meanings of the terms used are the same as in the aforementioned vehicle diagnostic scanning method based on standardized diagnostic data, and specific implementation details can be found in the descriptions in the method embodiments.

[0100] Please see Figure 4 , Figure 4 This is a schematic diagram of the structure of a vehicle diagnostic scanning device based on standardized diagnostic data provided in an embodiment of this application. Specifically, the vehicle diagnostic scanning device based on standardized diagnostic data may include an identifier acquisition module 201, a file acquisition module 202, a file parsing module 203, and a diagnostic scanning module 204, as follows: The identification acquisition module 201 is used to acquire the identification information of the target vehicle in response to receiving a diagnostic scan command for the target vehicle; The file acquisition module 202 is used to acquire a standardized diagnostic data file corresponding to the target vehicle from the cloud server based on the identification information. The standardized diagnostic data file includes the configuration information of the electronic control unit in the target vehicle. The file parsing module 203 is used to parse the standardized diagnostic data file and generate an electronic control unit (ECU) scan priority set. The ECU scan priority set includes at least one ECU address and its corresponding priority communication protocol. The diagnostic scanning module 204 is used to perform a diagnostic scan on the target vehicle according to the electronic control unit scanning priority set, send detection commands to each control unit address in order of priority communication protocol, determine the electronic control unit status based on the obtained response results, and generate diagnostic scan results.

[0101] Furthermore, such as Figure 5 As shown, in some embodiments, the apparatus further includes: The file update module 205 updates the standardized diagnostic data file based on the diagnostic scan results and uploads the updated standardized diagnostic data file to the cloud server.

[0102] Furthermore, in some embodiments, the identifier acquisition module 201 may specifically be used for: Connect the diagnostic equipment to the self-diagnostic interface of the target vehicle and establish a communication connection between the diagnostic equipment and the target vehicle. A vehicle identification code reading request is sent to the target vehicle's communication terminal via a communication connection. In response to a vehicle identification code reading request, the system receives and parses the corresponding response data, and extracts the corresponding vehicle identification code as identification information.

[0103] Furthermore, in some embodiments, the file acquisition module 202 may specifically be used for: The identification information is bound to the user equipment identifier, an encrypted configuration request is generated and sent to the cloud server; The system queries the vehicle's electronic control unit configuration archive based on the identification information via a cloud server and verifies the permissions of the currently requesting user. After authorization verification, the system retrieves the corresponding standardized diagnostic data file from the vehicle's electronic control unit configuration archive via the cloud server, encrypts and digitally signs it, and generates an encrypted file. The client receives the encrypted file and then performs digital signature verification. After digital signature verification, the encrypted file is decrypted locally to obtain a standardized diagnostic data file.

[0104] Furthermore, in some embodiments, the file parsing module 203 may specifically be used for: Call the local standardized diagnostic data file parsing engine to load the decrypted standardized diagnostic data file; Traverse the electronic control unit variant definition nodes in the standardized diagnostic data file to extract the logical name, physical address, and supported communication protocols of each electronic control unit; Based on preset rules or an electronic control unit protocol priority table synchronized from a cloud server, one or more priority communication protocols are determined for each electronic control unit address; The electronic control unit address and the corresponding priority communication protocol are assembled into a lightweight data structure to form the electronic control unit scan priority set.

[0105] Furthermore, in some embodiments, the diagnostic scanning module 204 may specifically be used for: Select the addresses of the electronic control units to be scanned in sequence according to the address sequence of the priority set for scanning electronic control units; For the current electronic control unit address, diagnostic session control requests are sent sequentially according to the order of the corresponding priority communication protocol list; Listen for bus responses. If a positive response is received within a preset timeout period, the existence of the electronic control unit is determined, the corresponding communication protocol is recorded, and the process jumps to the address of the next electronic control unit. If no positive response is received within the preset timeout period, the next priority communication protocol corresponding to the current electronic control unit address will be used until all communication protocols have been tried or a positive response is received.

[0106] Furthermore, in some embodiments, the file update module 205 may specifically be used for: The addresses, communication protocols, and service lists of the electronic control units that successfully responded to this scan were compared with the information recorded in the historical standardized diagnostic data files. If a new electronic control unit is identified, the electronic control unit address protocol support changes, or the electronic control unit service list is updated, it is determined to be a configuration change, and a new version of the standardized diagnostic data file and update log is generated. The new version of the standardized diagnostic data file is encrypted; The encrypted new version of the standardized diagnostic data file and update log are uploaded to the cloud server to update the vehicle electronic control unit configuration archive.

[0107] Furthermore, in some embodiments, such as Figure 5 As shown, the device also includes an aggregation analysis module 206, which can be used for: Anonymized diagnostic behavior logs are continuously collected from multiple clients via a cloud server. These logs include at least one of the following: vehicle platform, model year, region, ECU address, attempted communication protocols, and successful communication protocols. Anonymized diagnostic behavior logs are aggregated and analyzed based on a combination of vehicle platform, year, region, and electronic control unit address to calculate the successful connection rate and average response time for each protocol. Based on the successful connection rate and average response time, generate a protocol priority ranking for each electronic control unit address under each dimension combination; The priority sorting is encapsulated into a structured electronic control unit protocol priority table, and then sent to the client after being version-marked.

[0108] Furthermore, in some embodiments, the cloud server executes an access control policy when distributing standardized diagnostic data files or electronic control unit protocol priority tables. The access control policy includes at least one of verifying device fingerprints, verifying user subscription permissions, setting file download limit, and setting file validity time window.

[0109] Specific limitations regarding vehicle diagnostic scanning devices based on standardized diagnostic data can be found in the above description of limitations for vehicle diagnostic scanning methods based on standardized diagnostic data, and will not be repeated here. Each module in the aforementioned vehicle diagnostic scanning device based on standardized diagnostic data 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, or stored in the memory of a computer device as software, so that the processor can call and execute the corresponding operations of each module.

[0110] The vehicle diagnostic scanning device based on standardized diagnostic data provided in this embodiment first obtains a standardized diagnostic data file containing ECU configuration information from the cloud based on the target vehicle identification information, then parses and generates a scan priority set containing ECU addresses and corresponding priority communication protocols, and finally sends probe commands to the ECU addresses according to the priority communication protocol order and determines the ECU status. This effectively improves the efficiency of diagnostic scanning of the target vehicle, while reducing diagnostic errors caused by invalid operations and ensuring the accuracy of diagnostic scanning results.

[0111] Furthermore, embodiments of this application also provide an electronic device, such as... Figure 6 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 6 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.

[0112] The memory 302 can be used to store software programs and modules. The processor 301 executes various functional applications and vehicle diagnostic scanning methods based on standardized diagnostic data 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.

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

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

[0115] 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 receiving a diagnostic scan command for a target vehicle, the system acquires the target vehicle's identification information. Based on the identification information, it retrieves a standardized diagnostic data file corresponding to the target vehicle from a cloud server. This standardized diagnostic data file includes the configuration information of the electronic control units (ECUs) in the target vehicle. The system parses the standardized diagnostic data file to generate an ECU scan priority set, which includes at least one ECU address and its corresponding priority communication protocol. The system performs a diagnostic scan on the target vehicle according to the ECU scan priority set, sending probe commands to each ECU address in the order of the priority communication protocol. Based on the received response results, the system determines the ECU status and generates diagnostic scan results.

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

[0117] This application embodiment first obtains a standardized diagnostic data file containing ECU configuration information from the cloud based on the target vehicle identification information, then parses and generates a scan priority set containing the ECU address and corresponding priority communication protocol, and finally sends probe commands to the ECU address according to the priority communication protocol order and determines the ECU status. This effectively improves the efficiency of diagnostic scanning of the target vehicle, while reducing diagnostic errors caused by invalid operations and ensuring the accuracy of diagnostic scan results.

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

[0119] 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 vehicle diagnostic scanning methods based on standardized diagnostic data provided in embodiments of this application. For example, the instructions can execute the following steps: In response to receiving a diagnostic scan command for a target vehicle, the system acquires the target vehicle's identification information. Based on the identification information, it retrieves a standardized diagnostic data file corresponding to the target vehicle from a cloud server. This standardized diagnostic data file includes the configuration information of the electronic control units (ECUs) in the target vehicle. The system parses the standardized diagnostic data file to generate an ECU scan priority set, which includes at least one ECU address and its corresponding priority communication protocol. The system performs a diagnostic scan on the target vehicle according to the ECU scan priority set, sending probe commands to each ECU address in the order of the priority communication protocol. Based on the received response results, the system determines the ECU status and generates diagnostic scan results.

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

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

[0122] Since the instructions stored in the storage medium can execute the steps in any of the vehicle diagnostic scanning methods based on standardized diagnostic data provided in the embodiments of this application, the beneficial effects that any of the vehicle diagnostic scanning methods based on standardized diagnostic data provided in the embodiments of this application can achieve can be realized, as detailed in the preceding embodiments, and will not be repeated here.

[0123] The above provides a detailed description of a vehicle diagnostic scanning method and apparatus based on standardized diagnostic data 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. A vehicle diagnostic scanning method based on standardized diagnostic data, characterized in that, include: In response to receiving a diagnostic scan command for a target vehicle, the identification information of the target vehicle is obtained; Based on the identification information, a standardized diagnostic data file corresponding to the target vehicle is obtained from the cloud server. The standardized diagnostic data file includes the configuration information of the electronic control unit in the target vehicle. The standardized diagnostic data file is parsed to generate an electronic control unit (ECU) scan priority set, which includes at least one ECU address and its corresponding priority communication protocol. The target vehicle is diagnostically scanned according to the electronic control unit scan priority set. For each control unit address, a probe command is sent in order of priority communication protocol. The electronic control unit status is determined based on the obtained response results, and a diagnostic scan result is generated.

2. The vehicle diagnostic scanning method based on standardized diagnostic data according to claim 1, characterized in that, After generating the diagnostic scan results, the method further includes: The standardized diagnostic data file is updated based on the diagnostic scan results, and the updated standardized diagnostic data file is uploaded to the cloud server.

3. The vehicle diagnostic scanning method based on standardized diagnostic data according to claim 1, characterized in that, The step of receiving a diagnostic scan command for a target vehicle and obtaining the identification information of the target vehicle includes: The diagnostic device is connected to the self-diagnostic interface of the target vehicle, and a communication connection is established between the diagnostic device and the target vehicle. Through the communication connection, a vehicle identification code reading request is sent to the communication terminal of the target vehicle; In response to the vehicle identification code reading request, the system receives and parses the corresponding response data, and extracts the corresponding vehicle identification code as the identification information.

4. The vehicle diagnostic scanning method based on standardized diagnostic data according to claim 1, characterized in that, The step of obtaining the standardized diagnostic data file corresponding to the target vehicle from the cloud server based on the identification information includes: The identification information is bound to the user equipment identifier, an encrypted configuration request is generated and sent to the cloud server; The cloud server queries the vehicle electronic control unit configuration archive based on the identification information and verifies the permissions of the currently requesting user. After authorization verification, the cloud server retrieves the corresponding standardized diagnostic data file from the vehicle's electronic control unit configuration archive, encrypts and digitally signs it, and generates an encrypted file. The client receives the encrypted file and performs digital signature verification. After the digital signature is verified, the encrypted file is decrypted locally to obtain the standardized diagnostic data file.

5. The vehicle diagnostic scanning method based on standardized diagnostic data according to claim 1, characterized in that, The step of parsing the standardized diagnostic data file to generate an electronic control unit scan priority set includes: Call the local standardized diagnostic data file parsing engine to load the decrypted standardized diagnostic data file; Traverse the electronic control unit variant definition nodes in the standardized diagnostic data file to extract the logical name, physical address, and supported communication protocols of each electronic control unit; Based on preset rules or an electronic control unit protocol priority table synchronized from a cloud server, one or more priority communication protocols are determined for each electronic control unit address; The electronic control unit address and the corresponding priority communication protocol are assembled into a lightweight data structure to form the electronic control unit scan priority set.

6. The vehicle diagnostic scanning method based on standardized diagnostic data according to claim 1, characterized in that, The process of performing a diagnostic scan on the target vehicle based on the electronic control unit (ECU) scan priority set, sending probe commands to each ECU address according to the priority communication protocol sequence, determining the ECU status based on the received response results, and generating diagnostic scan results includes: According to the address sequence in the priority set of the electronic control unit scanning, the addresses of the electronic control units to be scanned are selected in sequence; For the current electronic control unit address, diagnostic session control requests are sent sequentially according to the order of the corresponding priority communication protocol list; Listen for bus responses. If a positive response is received within a preset timeout period, the existence of the electronic control unit is determined, the corresponding communication protocol is recorded, and the process jumps to the address of the next electronic control unit. If no positive response is received within the preset timeout period, the next priority communication protocol corresponding to the current electronic control unit address will be used until all communication protocols have been tried or a positive response is received.

7. The vehicle diagnostic scanning method based on standardized diagnostic data according to claim 2, characterized in that, The step of updating the standardized diagnostic data file based on the diagnostic scan results and uploading the updated standardized diagnostic data file to the cloud server includes: The addresses, communication protocols, and service lists of the electronic control units that successfully responded to this scan were compared with the information recorded in the historical standardized diagnostic data files. If a new electronic control unit is identified, the electronic control unit address protocol support changes, or the electronic control unit service list is updated, it is determined to be a configuration change, and a new version of the standardized diagnostic data file and update log are generated. The new version of the standardized diagnostic data file is encrypted; The encrypted new version of the standardized diagnostic data file and the update log are uploaded to the cloud server to update the vehicle electronic control unit configuration archive.

8. The vehicle diagnostic scanning method based on standardized diagnostic data according to claim 1, characterized in that, The method further includes: The cloud server continuously collects anonymized diagnostic behavior logs from multiple clients. These logs include at least one of the following: vehicle platform, model year, region, ECU address, attempted communication protocols, and successful communication protocols. The anonymized diagnostic behavior logs are aggregated and analyzed based on a combination of vehicle platform, year, region, and electronic control unit address to calculate the successful connection rate and average response time for each protocol. Based on the successful connection rate and the average response time, a protocol priority ranking is generated for each electronic control unit address under each dimension combination; The priority sorting is encapsulated into a structured electronic control unit protocol priority table, and after being version-marked, it is sent to the client.

9. The vehicle diagnostic scanning method based on standardized diagnostic data according to claim 8, characterized in that, When the cloud server distributes the standardized diagnostic data file or the electronic control unit protocol priority table, it executes an access control policy. The access control policy includes at least one of the following: verifying device fingerprints, verifying user subscription permissions, setting file download limit, and setting file validity time window.

10. A vehicle diagnostic scanning device based on standardized diagnostic data, characterized in that, include: The identification acquisition module is used to acquire the identification information of the target vehicle in response to receiving a diagnostic scan command for the target vehicle; The file acquisition module is used to acquire a standardized diagnostic data file corresponding to the target vehicle from the cloud server based on the identification information. The standardized diagnostic data file includes the configuration information of the electronic control unit in the target vehicle. The file parsing module is used to parse the standardized diagnostic data file and generate an electronic control unit (ECU) scan priority set, which includes at least one ECU address and its corresponding priority communication protocol. The diagnostic scanning module is used to perform a diagnostic scan on the target vehicle according to the electronic control unit scanning priority set, send detection commands to each control unit address in order of priority communication protocol, determine the electronic control unit status based on the obtained response results, and generate diagnostic scan results.

Images