Vehicle dynamic diagnosis method and device based on cache data, terminal equipment and storage medium

Abstract

The application is suitable for the technical field of vehicle electronic diagnosis, and provides a vehicle dynamic diagnosis method and device based on cache data, a terminal equipment and a storage medium, which comprises the following steps: obtaining a vehicle model configuration code corresponding to a vehicle to be diagnosed; wherein the vehicle model configuration code is used to represent the vehicle model version and configuration information of the vehicle to be diagnosed; in the case that the diagnosis cache data of the vehicle to be diagnosed is stored locally, obtaining the first vehicle model configuration information corresponding to the vehicle to be diagnosed from the diagnosis cache data according to the vehicle model configuration code; wherein the diagnosis cache data is used to represent a diagnosis data set corresponding to all configurations of the vehicle to be diagnosed; determining the first diagnosis data of the vehicle to be diagnosed from the diagnosis cache data according to the first vehicle model configuration information; and executing the first diagnosis data to diagnose the vehicle to be diagnosed. The above method can effectively improve the diagnosis efficiency of the vehicle and meet the actual needs of efficient automobile diagnosis.

Description

Technical Field

[0001] This application belongs to the field of vehicle electronic diagnostic technology, and in particular relates to a vehicle dynamic diagnostic method, device, terminal equipment and storage medium based on cached data. Background Technology

[0002] With the rapid development of automotive electronics technology, the number of electronic control units (ECUs) in vehicles that adopt Open Diagnostic Data Exchange (ODX) diagnostic technology is constantly increasing. Moreover, some ECUs have multiple suppliers, requiring the separate development of ODX and Open Toolkit foreXtended (OTX) files for each ECU and its corresponding supplier. This has led to a dramatic increase in the size of the vehicle diagnostic data package, which can reach hundreds of megabytes or even 1 GB. The most similar existing technical solution is the "local storage" strategy, which involves downloading the diagnostic data package from the server and encrypting it for the first time when diagnosing a certain vehicle model. When diagnosing the same vehicle model again, the locally stored data package is directly decrypted and parsed to obtain the diagnostic data. Although this existing technology reduces the time cost of repeated downloads, it still has the problems of needing to fully parse the huge ODX / OTX files, not being able to dynamically load data according to the actual vehicle configuration, and the parsing time being too long, which affects the diagnostic efficiency. Summary of the Invention

[0003] This application provides a vehicle dynamic diagnostic method based on cached data, which can effectively improve vehicle diagnostic efficiency and meet the actual needs of efficient vehicle diagnostics.

[0004] In a first aspect, embodiments of this application provide a vehicle dynamic diagnostic method based on cached data, including: Obtain the vehicle configuration code corresponding to the vehicle to be diagnosed; the vehicle configuration code is used to represent the vehicle model version and configuration information of the vehicle to be diagnosed. When the diagnostic cache data of the vehicle to be diagnosed is stored locally, the first vehicle configuration information corresponding to the vehicle to be diagnosed is obtained from the diagnostic cache data according to the vehicle configuration code; wherein, the diagnostic cache data is used to represent the set of diagnostic data corresponding to all configurations of the vehicle to be diagnosed; The first diagnostic data of the vehicle to be diagnosed is determined from the diagnostic cache data based on the first vehicle configuration information; Execute the first diagnostic data to diagnose the vehicle to be diagnosed.

[0005] In this embodiment, a unique vehicle configuration code is read from the diagnostic device and used as the core index for data matching. If the vehicle's diagnostic cache data (which covers a set of diagnostic data corresponding to all configurations of the vehicle model) is already stored locally, the first vehicle configuration information matching the actual configuration of the current vehicle is selected from the cache based on the vehicle configuration code. Then, based on the first vehicle configuration information, the vehicle-specific first diagnostic data is determined from the cache. Finally, the first diagnostic data is executed to complete the vehicle diagnosis. In this solution, the diagnostic resources corresponding to the actual configuration of the vehicle are directly located through the vehicle configuration code, eliminating the need to load diagnostic data for all redundant configurations of the vehicle model (such as excluding diagnostic data only available for other sub-models), reducing data processing volume, shortening diagnostic data combination time, and improving diagnostic efficiency.

[0006] In one possible implementation of the first aspect, the first diagnostic data of the vehicle to be diagnosed is determined from the diagnostic cache data based on the first vehicle configuration information, including: Based on the configuration information of the first vehicle model, determine at least one first control unit corresponding to the vehicle to be diagnosed and the first supplier corresponding to each first control unit; Obtain the first basic diagnostic data corresponding to each first control unit and the first dedicated diagnostic data corresponding to the first supplier from the diagnostic cache data; The first diagnostic data is obtained based on the first basic diagnostic data corresponding to each first control unit and the first dedicated diagnostic data corresponding to the first supplier.

[0007] In this embodiment, the first control unit and its corresponding first supplier actually installed in the vehicle to be diagnosed are first selected based on the first vehicle configuration information. Then, the first basic diagnostic data of each first control unit and the first exclusive diagnostic data of the corresponding supplier are extracted from the cache. Finally, the two types of data are merged to obtain the first diagnostic data. Its advantages are that only the diagnostic data actually required by the vehicle is loaded, avoiding redundant data processing. At the same time, the parsed data in the cache is reused, and there is no need to repeatedly parse the huge file, which greatly improves the efficiency of diagnostic data combination and diagnostic accuracy.

[0008] In one possible implementation of the first aspect, the first diagnostic data is obtained based on the first basic diagnostic data corresponding to each first control unit and the first specific diagnostic data corresponding to the first supplier, including: The first basic diagnostic data corresponding to a first control unit and the first dedicated diagnostic data corresponding to a first supplier are concatenated to obtain the first sub-diagnostic data; The first sub-diagnostic data corresponding to each of the first control units is determined as the first diagnostic data.

[0009] In this embodiment, first sub-diagnostic data is generated by concatenating the first basic diagnostic data (including common data such as public communication and standard fault codes) of each first control unit with the first dedicated diagnostic data (including personalized data such as unique fault codes and extended services) of the corresponding first supplier. Then, all the first sub-diagnostic data are aggregated to obtain the first diagnostic data. Its beneficial effect is to achieve accurate combination of diagnostic data, integrate only the ECU data actually required by the vehicle, avoid redundant data processing, and reuse the basic and dedicated data that have been parsed in the cache, without having to repeatedly parse huge files, which greatly improves the efficiency of diagnostic data generation and diagnostic accuracy.

[0010] In one possible implementation of the first aspect, the method further includes, before diagnosing the vehicle to be diagnosed: For each control unit corresponding to the same vehicle model, store the public diagnostic data of all suppliers corresponding to the control unit in the first preset file; The dedicated diagnostic data for each supplier corresponding to the control unit is stored in a second preset file corresponding to each supplier.

[0011] In this embodiment, for each control unit of the same vehicle model, all public diagnostic data from all suppliers are stored in a first preset file, while the proprietary diagnostic data from each supplier are stored in their respective second preset files. The advantage of this is that it achieves separate storage of public and proprietary data, avoids data redundancy to reduce data packet size, and lays a structured foundation for rapid matching and dynamic combination of required diagnostic data according to vehicle model configuration codes during subsequent diagnosis. It eliminates the need to repeatedly parse complete and large ODX / OTX files, greatly improving diagnostic efficiency and reducing network bandwidth consumption.

[0012] In one possible implementation of the first aspect, the method further includes: Set up a vehicle configuration table; the vehicle configuration table contains a version configuration list for all vehicle versions corresponding to the vehicle model; each version configuration list contains all control units corresponding to the vehicle version, the supplier for each control unit, and the second preset file for each supplier; Store the vehicle configuration table in a third preset file; A diagnostic data package corresponding to each vehicle model is constructed based on the first preset file, the second preset file, the third preset file, and the communication parameter file corresponding to the control unit.

[0013] In this embodiment, a vehicle configuration table (including the control unit of each configuration, the corresponding supplier, and the supplier's second preset file) covering all configurations of the vehicle model is first set and stored in a third preset file. Then, a vehicle diagnostic data package is constructed by combining the first preset file (public diagnostic data), the second preset file (supplier-specific diagnostic data), the third preset file (vehicle configuration table), and the control unit communication parameter file. The beneficial effect is that it realizes the structured classification, storage, and association of diagnostic data, laying the foundation for subsequent initial diagnostic parsing, caching, and subsequent diagnosis through dynamic combination of data using vehicle configuration codes, avoiding data package redundancy, and eliminating repeated download and complete parsing steps, greatly improving diagnostic efficiency and reducing network bandwidth consumption.

[0014] In one possible implementation of the first aspect, the method further includes: If the diagnostic cache data of the vehicle to be diagnosed is not stored locally, download the corresponding diagnostic data package of the vehicle to be diagnosed according to the vehicle configuration code; The diagnostic data package contains multiple files, which are then parsed to obtain the parsed data. The parsed data is stored in a local preset area to obtain diagnostic cache data; Diagnose the data to be diagnosed based on cached data.

[0015] In this embodiment, when the diagnostic cache data of the vehicle to be diagnosed is not stored locally, the corresponding diagnostic data package is first downloaded according to the vehicle configuration code. Multiple files in the data package are parsed to obtain parsed data, which is then stored in a local preset area to form diagnostic cache data. The vehicle to be diagnosed is then diagnosed based on the cache data. Its beneficial effect is to realize the diagnostic data "download once, parse once, and reuse permanently". Subsequent diagnoses of the same vehicle model do not require repeated downloading of large data packages and complete parsing files, which greatly reduces network bandwidth consumption and data processing time, and significantly improves diagnostic efficiency.

[0016] In one possible implementation of the first aspect, the diagnostic data packet is parsed to obtain parsed data, including: The third preset file in the diagnostic data package is parsed to obtain a version configuration list of all configurations of the vehicle to be diagnosed. Parse the first preset file corresponding to each control unit in the diagnostic data package to obtain the basic diagnostic data corresponding to each preset file; Parse multiple second-preset files in the diagnostic data package to obtain the unique diagnostic data for each vendor; The version configuration list, multiple basic diagnostic data, and multiple exclusive diagnostic data are recorded as parsed data.

[0017] In this embodiment, the third preset file (obtaining a version configuration list of all configurations of the vehicle model), the first preset file (obtaining basic diagnostic data) corresponding to each control unit, and multiple second preset files (obtaining diagnostic data specific to each supplier) in the diagnostic data package are parsed separately, and the three types of data are recorded as parsed data. The beneficial effect is that it realizes the structured splitting and parsing of diagnostic data, which lays the foundation for the subsequent dynamic combination of the actual diagnostic data required by the vehicle according to the vehicle model configuration code, while avoiding the repeated parsing of redundant data, and greatly improving the efficiency and accuracy of subsequent diagnostic data combination.

[0018] Secondly, embodiments of this application provide a vehicle dynamic diagnostic device based on cached data, comprising: The vehicle model acquisition module is used to obtain the vehicle model configuration code corresponding to the vehicle to be diagnosed; the vehicle model configuration code is used to represent the vehicle model and configuration information of the vehicle to be diagnosed. The vehicle configuration information acquisition module is used to retrieve the first vehicle configuration information corresponding to the vehicle to be diagnosed from the diagnostic cache data based on the vehicle configuration code, when the diagnostic cache data of the vehicle to be diagnosed is stored locally; wherein, the diagnostic cache data is used to represent the complete set of diagnostic data of the vehicle to be diagnosed; The diagnostic data determination module is used to determine the first diagnostic data of the vehicle to be diagnosed from the diagnostic cache data based on the first vehicle configuration information. The vehicle diagnostic module is used to execute the first diagnostic data to diagnose the vehicle's equipment.

[0019] Thirdly, embodiments of this application provide a terminal device, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the vehicle dynamic diagnosis method based on cached data as described in any of the first aspects above.

[0020] Fourthly, embodiments of this application provide a computer-readable storage medium storing a computer program that, when executed by a processor, implements the vehicle dynamic diagnosis method based on cached data as described in any of the first aspects above.

[0021] Fifthly, embodiments of this application provide a computer program product that, when run on a terminal device, causes the terminal device to execute the vehicle dynamic diagnosis method based on cached data as described in any of the first aspects above.

[0022] It is understood that the beneficial effects of the second to fifth aspects mentioned above can be found in the relevant descriptions in the first aspect mentioned above, and will not be repeated here. Attached Figure Description

[0023] To more clearly illustrate the technical solutions in the embodiments of this application, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the 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.

[0024] Figure 1 This is a schematic diagram of the data preprocessing process provided in the embodiments of this application. Figure 1 ; Figure 2 This is a schematic diagram of the data preprocessing process provided in the embodiments of this application. Figure 2 ; Figure 3 This is a flowchart illustrating the vehicle dynamic diagnostic method based on cached data provided in the embodiments of this application. Figure 1 ; Figure 4 This is a flowchart illustrating the data parsing process provided in an embodiment of this application; Figure 5 This is a flowchart illustrating the vehicle dynamic diagnostic method based on cached data provided in the embodiments of this application. Figure 2 ; Figure 6 This is a schematic flowchart of the process for determining the first diagnostic data provided in the embodiments of this application. Figure 1 ; Figure 7 This is a schematic flowchart of the process for determining the first diagnostic data provided in the embodiments of this application. Figure 2 ; Figure 8 This is a schematic diagram of the vehicle data structure after parsing the diagnostic data packet provided in an embodiment of this application; Figure 9 This is a schematic diagram illustrating an example of the basic diagnostic data structure provided in an embodiment of this application; Figure 10 This is an example diagram of the supplier-specific diagnostic data structure provided in the embodiments of this application; Figure 11 This is an example diagram of the real vehicle data structure formed after dynamically trimming diagnostic data according to the embodiments of this application; Figure 12 This is a schematic diagram of the initial diagnostic process structure provided in the embodiments of this application; Figure 13 This is a schematic diagram of the subsequent diagnostic process structure provided in the embodiments of this application; Figure 14 This is a structural block diagram of the vehicle dynamic diagnostic device based on cached data provided in the embodiments of this application; Figure 15 This is a schematic diagram of the structure of the terminal device provided in the embodiments of this application. Detailed Implementation

[0025] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application may also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted so as not to obscure the description of this application with unnecessary detail.

[0026] It should be understood that, when used in this application specification and the appended claims, the term "comprising" indicates the presence of the described features, integrals, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or a collection thereof.

[0027] It should also be understood that the term “and / or” as used in this application specification and the appended claims means any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.

[0028] As used in this application specification and the appended claims, the term "if" may be interpreted, depending on the context, as "when," "once," "in response to determination," or "in response to detection." Similarly, the phrases "if determined" or "if detected [the described condition or event]" may be interpreted, depending on the context, as meaning "once determined," "in response to determination," "once detected [the described condition or event]," or "in response to detection [the described condition or event]."

[0029] Furthermore, in the description of this application and the appended claims, the terms "first," "second," "third," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0030] References to "one embodiment" or "some embodiments" in this specification mean that one or more embodiments of this application include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized.

[0031] With the rapid development of automotive electronics technology, the number of ECUs in vehicles using ODX diagnostic technology is constantly increasing, and some ECUs have multiple suppliers. ODX and OTX files need to be developed separately for each ECU and its corresponding supplier, resulting in a sharp increase in the size of the whole vehicle diagnostic data package, which can reach hundreds of megabytes or even 1GB. The most similar existing technical solution is the "local storage" strategy, which involves downloading the diagnostic data package from the server and encrypting it for the first time when diagnosing a certain vehicle model. When diagnosing the same vehicle model again, the locally stored data package is directly decrypted and parsed to obtain the diagnostic data. Although this existing technology reduces the time cost of repeated downloads, it still has the problems of needing to fully parse the huge ODX / OTX files, not being able to dynamically load data according to the actual vehicle configuration, and the parsing time being too long, which affects the diagnostic efficiency.

[0032] To address the aforementioned technical issues, this application provides a vehicle dynamic diagnostic method based on cached data. By classifying and storing diagnostic data (ECU common data is stored in BV files, supplier-specific data is stored in corresponding EV files, and V files establish mapping relationships), parsing and encrypting cached data during the initial diagnostic test, and dynamically combining data for subsequent diagnostic tests, this method avoids repeated downloads and complete parsing, reduces network consumption and waiting time, and significantly improves diagnostic efficiency.

[0033] In one embodiment, see Figure 1 This is a schematic diagram of the data preprocessing process provided in the embodiments of this application. Figure 1 ,like Figure 1 As shown, it includes: S101, for each control unit corresponding to the same vehicle model, store the public diagnostic data of all suppliers corresponding to the control unit in the first preset file.

[0034] In this embodiment of the application, when developing vehicle diagnostic data packages, it is necessary to package the ODX-OTX source files of all ECUs of the entire vehicle. This solves the problem of diagnostic data package redundancy caused by multiple supplier ECUs by using the method of "centralized storage of public data and split storage of private data".

[0035] Specifically, for each ECU under the same vehicle model, such as the Air Conditioning Control Unit (AC) and the Engine Management System (EMS), if the control unit has multiple suppliers, such as SUP1 and SUP2 suppliers for AC, the diagnostic data that is common to these suppliers (i.e., common data that does not distinguish between suppliers) is centrally stored in a unified first preset file. The first preset file is the basic supplier data file (which can be referred to as the BV file). Its core purpose is to avoid the duplicate storage of common data and lay the foundation for subsequent rapid retrieval and data reuse.

[0036] S102, store the exclusive diagnostic data of each supplier corresponding to the control unit in the second preset file corresponding to each supplier.

[0037] In this embodiment, the core of the dedicated data storage rule in the diagnostic data package development stage is to allocate a dedicated storage medium, namely a second preset file, to each supplier of the same control unit (ECU). For example, the second preset file is an extended supplier-specific data file (EV file) used to store the unique diagnostic data of that supplier, so as to realize the accurate differentiation and independent management of personalized data of different suppliers, and provide support for loading data on demand during subsequent diagnosis.

[0038] For example, during the development of vehicle diagnostic data packages, for each supplier of the same ECU, technicians will first sort out and filter out the diagnostic data unique to that supplier, including supplier-specific fault codes, extended service functions, exclusive configuration parameters, personalized diagnostic logic, etc. Then, these exclusive data are stored separately in an EV file, and a differentiated naming rule of "ECU name + supplier abbreviation" is adopted (e.g., the SUP1 supplier of ACECU corresponds to "AC_EV_SUP1", and the SUP2 supplier corresponds to "AC_EV_SUP2") to ensure that each supplier has a unique corresponding EV file and avoid confusion.

[0039] In the above method, for each control unit of the same vehicle model, all public diagnostic data from all suppliers are stored in a first preset file, while the proprietary diagnostic data from each supplier is stored in a corresponding second preset file. The advantage of this method is that it achieves separate storage of public and proprietary data, avoids data redundancy to reduce data packet size, and lays a structured foundation for quickly matching and dynamically combining the required diagnostic data according to the vehicle configuration code during subsequent diagnosis. It eliminates the need to repeatedly parse the complete and large ODX / OTX file, greatly improves diagnostic efficiency and reduces network bandwidth consumption.

[0040] In one embodiment, see Figure 2This is a schematic diagram of the data preprocessing process provided in the embodiments of this application. Figure 2 ,like Figure 2 As shown, it includes: S201, Set the vehicle configuration table; wherein, the vehicle configuration table contains a version configuration list of all vehicle versions corresponding to the vehicle model; wherein, each version configuration list contains all control units corresponding to the vehicle version, the supplier corresponding to each control unit, and the second preset file corresponding to each supplier.

[0041] In this embodiment of the application, a "vehicle configuration table" is constructed. This table needs to cover all configuration versions of the same vehicle model. For each configuration version, all control units (ECUs) it contains, the actual supplier of each control unit, and the "second preset file" (which can be referred to as EV file) corresponding to the supplier's exclusive diagnostic data are clearly listed. Essentially, this establishes a precise mapping relationship between "vehicle configuration - ECU - supplier - EV file" to provide an index for quickly locating data during subsequent diagnosis.

[0042] For example, firstly, all configuration versions of the vehicle model are identified (e.g., the Premium, Luxury, and Fashion versions of the 2024 Mercedes-Benz E300L), and a unique vehicle code (VehicleCode, e.g., 001F2024030200 corresponds to the Premium version) is assigned to each configuration version. Next, for each configuration version, all control units included are identified (e.g., the Premium version includes AC, EMS, TCM, and ESC), and the actual supplier of each control unit is recorded (e.g., SUP1 corresponds to AC, and SUP1 corresponds to EMS). Finally, the EV file corresponding to each supplier is associated (e.g., the SUP1 supplier for AC corresponds to "AC_EV_SUP1").

[0043] S202, store the vehicle configuration table in a third preset file.

[0044] In this embodiment of the application, the "vehicle configuration table" mentioned above (which includes a list of ECUs for all configurations of the same vehicle model, the corresponding suppliers of each ECU, and the association relationship between the supplier's exclusive second preset file / EV file) is uniformly stored in a designated "third preset file". For example, the third preset file is a vehicle configuration mapping file (which can be referred to as a V file). The purpose is to centrally manage the configuration mapping information and facilitate quick reading and parsing during subsequent diagnosis.

[0045] Specifically, all configuration versions of the vehicle model (such as the 2024 Mercedes-Benz E300L's Premium, Luxury, and Fashion models) are identified, and a unique VehicleCode is assigned to each configuration version. Then, for each configuration version, all ECUs included, the actual supplier of each ECU, and the corresponding EV file name and path are identified. This information is then structured and entered into a V file in XML format. Different configuration versions are distinguished by SDG tags (SI attributes correspond to VehicleCode), and the association between ECUs and suppliers under each configuration is recorded by SD tags, forming a complete vehicle configuration table. Finally, this V file, along with the BV file, EV file, communication parameter file, and OTX file, is packaged into a vehicle diagnostic data package. During subsequent diagnostics, the diagnostic software can directly read and parse this V file to quickly obtain the mapping relationship between vehicle configurations and ECUs, suppliers, and EV files, providing an index for dynamic data combination.

[0046] S203, construct a diagnostic data package corresponding to each vehicle model based on the first preset file, the second preset file, the third preset file and the communication parameter file corresponding to the control unit.

[0047] In this embodiment, four types of key files (first preset file / BV file, second preset file / EV file, third preset file / V file, and communication parameter file / -c / -cs file corresponding to the control unit) are integrated and combined with OTX file (advanced diagnostic function file) to form a diagnostic data package specific to a certain vehicle model, providing a complete file foundation for data download, parsing and reuse during subsequent diagnosis.

[0048] For example, common diagnostic data from multiple suppliers for each control unit (ECU) of the same vehicle model is stored in the corresponding BV file (first preset file), and the exclusive diagnostic data of each supplier is stored in the corresponding EV file (second preset file with differentiated naming). The ECU list, supplier and EV file associations of all configurations of the vehicle model are sorted out to form a vehicle configuration table and stored in the V file (third preset file). At the same time, the communication protocols, addresses and other information of each ECU are sorted to form a -c / -cs communication parameter file. Then, common and supplier-specific advanced diagnostic function files (OTX files) are prepared. Subsequently, all files are integrated according to a fixed directory structure, and a vehicle-specific folder is created (named with the vehicle model identifier such as "001F"). The V file, the BV file corresponding to each ECU, the EV files of all suppliers, the -c / -cs communication parameter files of each ECU, and the exclusive subfolders for storing ODX files and OTX files are included together. Finally, they are compressed and packaged into a complete diagnostic data package for the vehicle model (such as "VehicleDiagnoseData.zip"), which is convenient for the diagnostic software to download and use according to the vehicle model.

[0049] The above method first sets up a vehicle configuration table covering all configurations of the vehicle (including the control unit of each configuration, the corresponding supplier, and the supplier's second preset file) and stores it in a third preset file. Then, it combines the first preset file (public diagnostic data), the second preset file (supplier-specific diagnostic data), the third preset file (vehicle configuration table), and the control unit communication parameter file to construct a vehicle diagnostic data package. Its beneficial effect is to realize the structured classification, storage, and association of diagnostic data, which lays the foundation for subsequent initial diagnostic parsing, caching, and subsequent diagnosis through dynamic combination of data using vehicle configuration codes, avoids data package redundancy, and eliminates repeated download and complete parsing steps, greatly improving diagnostic efficiency and reducing network bandwidth consumption.

[0050] In one embodiment, see Figure 3 This is a flowchart illustrating the vehicle dynamic diagnosis method based on cached data provided in this application embodiment. Figure 1 ,like Figure 3 As shown, it includes: S301: If the diagnostic cache data of the vehicle to be diagnosed is not stored locally, download the diagnostic data package corresponding to the vehicle to be diagnosed based on the vehicle configuration code.

[0051] In this embodiment, when the diagnostic device does not store the diagnostic cache data of the vehicle to be diagnosed locally, the diagnostic software will read the vehicle's unique vehicle configuration code (VehicleCode) to accurately locate and download the complete diagnostic data package corresponding to the vehicle configuration from the server, providing basic file support for subsequent data parsing, cache storage and diagnostic work.

[0052] For example, after the diagnostic software starts, it first establishes a connection with the vehicle to be diagnosed and reads the vehicle's model configuration code (a hexadecimal string defined by the manufacturer, such as 001F2024030200, which uniquely identifies the model, year, and sub-model configuration). Then, the diagnostic software checks the local storage directory (folders created according to model identification) to determine whether there is encrypted cache data corresponding to the model configuration code (including structured data such as Vehicle_Config, Basic_DiagData, and Child_DiagData_SupName). If the corresponding cache is not found locally, the software will send a data request to the server based on the read model configuration code. The server matches the corresponding whole vehicle diagnostic data package (containing V files, BV files of each ECU, EV files of all suppliers, -c / -cs communication parameter files, OTX files, etc., packaged into a compressed package such as "VehicleDiagnoseData.zip") based on the configuration code, and transmits it to the diagnostic device. After receiving it, the software saves the data package to the local dedicated folder of the corresponding model, completing the download process and preparing for the subsequent parsing steps.

[0053] S302, parses the multiple files contained in the diagnostic data packet to obtain parsed data.

[0054] In this embodiment, after the diagnostic software downloads the complete diagnostic data package of the vehicle to be diagnosed, it parses the various types of files contained in the data package, such as V files, BV files, EV files, -c / -cs communication parameter files, and OTX files, one by one according to preset logic, extracting configuration mapping information, common diagnostic data, supplier-specific data, communication parameters, advanced diagnostic functions, etc., and converting them into structured parsed data (Vehicle_Config, Basic_DiagData, Child_DiagData_SupName, etc.), providing a foundation for subsequent cache storage and diagnostic data combination.

[0055] In one embodiment, see Figure 4 This is a flowchart illustrating the data parsing process provided in an embodiment of this application, such as... Figure 4 As shown, step S302 includes: S401, parse the third preset file in the diagnostic data package to obtain a version configuration list of all configurations of the vehicle to be diagnosed.

[0056] In this embodiment, after the diagnostic software downloads and decompresses the diagnostic data package, it parses the "third preset file" (i.e., V file, vehicle configuration mapping file) to extract detailed information corresponding to all configuration versions of the vehicle model, forming a "version configuration list" containing the control units (ECUs) involved in each configuration version, the corresponding suppliers of the ECUs, and related files, providing a core index for subsequent matching of the actual configuration of the vehicle to be diagnosed and locating the required data.

[0057] Specifically, after the diagnostic software decompresses the diagnostic data package, it locates the V file (the third preset file) and starts the parsing process: First, it identifies different vehicle configuration versions distinguished by SDG tags in the V file. The SI attribute of each SDG tag corresponds to a unique vehicle configuration code (VehicleCode, such as 001F2024030200 corresponding to the 2024 Mercedes-Benz E300L Premium). Then, it parses the SD sub-tags under each SDG tag to extract the names of all control units (ECUs) included in that configuration version (such as AC, EMS, TCM, etc.) and the supplier corresponding to each ECU (such as AC corresponding to SUP1, EMS corresponding to SUP2). At the same time, it associates the EV files (the second preset file) and OTX file path information corresponding to each supplier recorded in the V file, and finally compiles them into a version configuration list covering all configuration versions of the vehicle. The list clearly defines the configuration code, ECU list, ECU-supplier correspondence and associated file information for each configuration version, laying the foundation for subsequent identification of the actual configuration of the vehicle to be diagnosed.

[0058] S402, parse the first preset file corresponding to each control unit in the diagnostic data package to obtain the basic diagnostic data corresponding to each preset file.

[0059] In this embodiment of the application, after parsing the V file, i.e. the third preset file, the diagnostic software then parses the "first preset file" (i.e. the BV file, basic supplier data file) corresponding to each control unit (ECU) separately when parsing the diagnostic data package. It extracts the common data that is common to multiple suppliers for the ECU and forms a structured "basic diagnostic data" (Basic_DiagData), which provides a common basic support for subsequent combination with supplier-specific data.

[0060] Specifically, after decompressing the diagnostic data package, the diagnostic software first locates the corresponding BV file for each control unit at the ECU level (e.g., ACECU corresponds to the AC_BV file, EMSECU corresponds to the EMS_BV file), and then performs analysis in conjunction with the ECU's -c / -cs communication parameter file: First, it extracts the ECU's communication-related data from the -c / -cs file, including communication protocols, device addresses, transmission parameters, etc., and stores it in the communication data module of the basic diagnostic data; then, it parses the BV file to extract diagnostic data common to all suppliers, covering standard fault codes (DTCs), basic diagnostic service functions, unified menu structure, and general... Data elements are added to the diagnostic data module of the basic diagnostic data; at the same time, the common OTX file (with the word "Basic") corresponding to the ECU is parsed, compiled into a directly callable Basic_AdvancedFunc.dll file, and the calling interface information of the dll file is recorded and incorporated into the advanced function module of the basic diagnostic data; finally, a structured basic diagnostic data (Basic_DiagData) is formed for each ECU, containing communication data, diagnostic data, menus, and advanced function interfaces, and the basic diagnostic data structure of all ECUs is consistent, which facilitates subsequent unified management and combination.

[0061] S403 parses multiple second preset files in the diagnostic data package to obtain the unique diagnostic data for each vendor.

[0062] In this embodiment, after parsing the V file (third preset file) and the BV file (second preset file), the EV file (second preset file) is finally parsed. Each of the multiple "second preset files" (i.e. EV files, extended supplier-specific data files) is parsed one by one, and the corresponding supplier-specific diagnostic information is extracted from each EV file to form structured "dedicated diagnostic data" (named "Child_DiagData_SupName", where SupName is the supplier's abbreviation), which provides personalized data support for subsequent combination with basic diagnostic data and accurate adaptation to the actual vehicle configuration.

[0063] S404 records the version configuration list, multiple basic diagnostic data, and multiple exclusive diagnostic data as parsed data.

[0064] In this application embodiment, the “version configuration list” obtained by parsing the third preset file (V file), the “multiple basic diagnostic data” obtained by parsing the first preset file (BV file) corresponding to each control unit (ECU), and the “multiple exclusive diagnostic data” obtained by parsing multiple second preset files (EV files) are uniformly classified as “parsed data” to form a structured and complete data set that can be directly used for cache storage and subsequent data combination.

[0065] Specifically, after the diagnostic software completes the full file parsing of the diagnostic data package according to the preset process, it classifies and integrates the parsing results: First, the ECU list, ECU-supplier association, and EV file mapping information obtained from parsing the V file, which covers all configuration versions of the vehicle model, are clearly defined as the "Version Configuration List"; Second, the structured public data (including communication data, general diagnostic data, basic menus, general advanced function interfaces, etc.) generated by parsing the BV file, -c / -cs communication parameter file, and common OTX file at the ECU level are uniformly classified as "Multiple Basic Diagnostic Data" (one for each ECU); Finally, the structured personalized data (including supplier-specific fault codes, extended services, etc.) named "Child_DiagData_SupName" generated by parsing each EV file and supplier-specific OTX file are classified as "Multiple Dedicated Diagnostic Data" (one for each supplier); Finally, these three types of data are integrated and marked as "Parsed Data," providing a clear data classification basis for subsequent encrypted cache storage and dynamic data combination during diagnosis.

[0066] In the above method, the third preset file (obtaining the version configuration list of all configurations of the vehicle model), the first preset file corresponding to each control unit (obtaining basic diagnostic data), and multiple second preset files (obtaining the exclusive diagnostic data of each supplier) in the diagnostic data package are analyzed separately, and the three types of data are recorded as the parsed data. Its beneficial effect is to realize the structured splitting and parsing of diagnostic data, which lays the foundation for the subsequent dynamic combination of the actual diagnostic data required by the vehicle according to the vehicle model configuration code, while avoiding the repeated parsing of redundant data, and greatly improving the efficiency and accuracy of subsequent diagnostic data combination.

[0067] S303 stores the parsed data in a local preset area to obtain diagnostic cache data.

[0068] In this embodiment, the complete parsed data obtained during the initial diagnostic analysis (including the version configuration list / Vehicle_Config, basic diagnostic data of multiple ECUs / Basic_DiagData, and dedicated diagnostic data of multiple suppliers / Child_DiagData_SupName) is stored in encrypted form in a preset storage area on the local machine of the diagnostic device, forming a "diagnostic cache data" specific to the vehicle model. This provides a basis for cache reuse and rapid data combination during subsequent diagnostic analysis of the same vehicle model.

[0069] Specifically, after the diagnostic software completes the full parsing of the diagnostic data package, it first structures and organizes the three types of core data obtained from the parsing (Vehicle_Config version configuration list, Basic_DiagData for each ECU, and Child_DiagData_SupName for each supplier) to ensure that the data format is consistent (such as using JSON / XML or database format), and that Basic_DiagData and Child_DiagData_SupName have the same data structure (both contain modules such as communication data, diagnostic data, menus, and advanced function interfaces). Then, it starts the encryption process to encrypt the organized and complete parsed data to prevent data leakage. Next, in the local preset storage area of ​​the diagnostic device (creating dedicated folders according to vehicle type, named with vehicle type identifiers such as "001F"), it creates a cache data file for that vehicle type, stores the encrypted parsed data in it, and saves it together with the downloaded original diagnostic data package in the corresponding vehicle type folder, thus forming the diagnostic cache data for that vehicle type. It can be directly read and decrypted during subsequent diagnostics without repeated downloading and parsing.

[0070] S304, performs diagnosis based on cached data and the data to be diagnosed.

[0071] In this embodiment, by decrypting cached data, matching the actual vehicle configuration based on the vehicle configuration code, and dynamically combining basic diagnostic data with supplier-specific diagnostic data, complete diagnostic data required by the vehicle is formed, thereby enabling efficient diagnostic work.

[0072] In the above method, when the diagnostic cache data of the vehicle to be diagnosed is not stored locally, the corresponding diagnostic data package is first downloaded according to the vehicle configuration code. Multiple files in the data package are parsed to obtain the parsed data and stored in a local preset area to form diagnostic cache data. Then, the vehicle to be diagnosed is diagnosed based on the cache data. Its beneficial effect is to realize the diagnostic data "download once, parse once, and reuse permanently". Subsequent diagnoses of the same vehicle model do not need to repeatedly download the huge data package and complete parsing file, which greatly reduces network bandwidth consumption and data processing time, and significantly improves diagnostic efficiency.

[0073] See Figure 5 This is a flowchart illustrating the vehicle dynamic diagnosis method based on cached data provided in this application embodiment. Figure 2 As an example and not a limitation, a method may include the following steps: S501, obtain the vehicle model configuration code corresponding to the vehicle to be diagnosed; whereby the vehicle model configuration code is used to indicate the vehicle model version and configuration information of the vehicle to be diagnosed.

[0074] In this embodiment of the application, a unique "Vehicle Code" is obtained for the vehicle to be diagnosed. This code is a hexadecimal string defined by the manufacturer, which can accurately identify the specific model, year, and sub-model configuration of the vehicle (such as the 2024 Mercedes-Benz E300L Premium). It is the core index basis for subsequent matching of diagnostic data packages, location of cached data, and dynamic combination of diagnostic data.

[0075] For example, after the diagnostic software starts, it first establishes a communication connection with the vehicle to be diagnosed through the diagnostic device (VCI). Using the vehicle's OBD interface or dedicated communication protocol, it reads the vehicle model and configuration-related low-level information stored in the vehicle control system. Then, according to the manufacturer's preset encoding rules, it converts this information into a unique hexadecimal string (i.e., the vehicle configuration code). The code contains clear segment meanings (e.g., the first four digits "001F" represent the specific model Mercedes-Benz E300L, the middle four digits "2024" represent the year, and the last six digits "030200" represent the sub-model premium version). Finally, the diagnostic software obtains and stores the vehicle configuration code, which is used to subsequently determine whether there is corresponding cached data locally, download the matching diagnostic data package from the server, and locate the diagnostic resources corresponding to the actual vehicle configuration in the cached data.

[0076] S502, when the diagnostic cache data of the vehicle to be diagnosed is stored locally, the first vehicle configuration information corresponding to the vehicle to be diagnosed is obtained from the diagnostic cache data according to the vehicle configuration code; wherein, the diagnostic cache data is used to represent the set of diagnostic data corresponding to all configurations of the vehicle to be diagnosed.

[0077] In this embodiment of the application, when the diagnostic device has stored the diagnostic cache data of the vehicle to be diagnosed locally (the cache covers a set of diagnostic data for all configurations of the vehicle model), the diagnostic software will accurately filter out the "first vehicle model configuration information" (i.e., the ECU list, ECU suppliers and associated file mapping relationship corresponding to the actual configuration of the current vehicle) from the cache data based on the read vehicle model configuration code, so as to provide an accurate index for loading the corresponding diagnostic data later.

[0078] For example, after confirming the existence of diagnostic cache data for the vehicle to be diagnosed locally, the diagnostic software first decrypts the encrypted cache data (including the Vehicle_Config version configuration list, Basic_DiagData for each ECU, and Child_DiagData_SupName for each supplier); then it extracts the structured Vehicle_Config data from the cache (this data is generated by parsing the V file during the initial diagnosis and records the mapping relationship between the configuration codes of all configuration versions of the vehicle model and the ECU and supplier); next, it matches the currently read vehicle model configuration code (e.g., 001F2024030200) with the configuration codes corresponding to each configuration version recorded in Vehicle_Config; after finding a completely matching configuration entry, it extracts all the information under that entry, namely the "first vehicle model configuration information", including the actual list of ECUs included in the current vehicle (e.g., AC, EMS, TCM, ESC), the specific supplier corresponding to each ECU (e.g., AC corresponds to SUP1, EMS corresponds to SUP1), and the EV file name and associated path corresponding to each supplier, preparing for the subsequent accurate loading of basic diagnostic data and dedicated diagnostic data.

[0079] S503, based on the first vehicle configuration information, determines the first diagnostic data of the vehicle to be diagnosed from the diagnostic cache data.

[0080] In this embodiment of the application, based on the "first vehicle configuration information" (the list of ECUs corresponding to the actual configuration of the current vehicle and each ECU supplier) obtained from the cache, the basic diagnostic data required for the configuration and the exclusive diagnostic data of the corresponding supplier are filtered and matched from the diagnostic cache data, and finally aggregated to form the unique "first diagnostic data" (i.e. the complete diagnostic data of the whole vehicle) of the vehicle to be diagnosed, providing direct and usable data support for efficient diagnosis.

[0081] In one embodiment, see Figure 6 This is a flowchart illustrating the process of determining the first diagnostic data provided in an embodiment of this application. Figure 1 ,like Figure 6 As shown, step S503 includes: S601, based on the first vehicle configuration information, determine at least one first control unit corresponding to the vehicle to be diagnosed and a first supplier corresponding to each first control unit.

[0082] In the embodiments of this application, S602, retrieve the first basic diagnostic data corresponding to each first control unit and the first dedicated diagnostic data corresponding to the first supplier from the diagnostic cache data.

[0083] In this embodiment, based on the "first vehicle configuration information" (the mapping data corresponding to the actual configuration of the current vehicle) obtained from the diagnostic cache data, two types of key information are further filtered and extracted: "at least one first control unit (ECU)" actually installed in the vehicle to be diagnosed (i.e., the list of ECUs actually equipped in the vehicle), and "first supplier" (i.e., the actual supplier of the ECU) corresponding to each first control unit, so as to provide a direct basis for the subsequent accurate loading of the corresponding basic diagnostic data and dedicated diagnostic data.

[0084] For example, after the diagnostic software decrypts the diagnostic cache data and obtains the first vehicle configuration information, it focuses on the configuration entries in this information that completely match the current vehicle configuration code (VehicleCode): First, from the ECU records under this entry (such as the ECU information corresponding to the SD tag), it filters out the control units actually installed in the current vehicle. These control units are the "first control units" (such as the AC, EMS, TCM, ESC, etc. ECUs corresponding to the 2024 Mercedes-Benz E300L Premium model), excluding redundant ECUs that are only present in other configuration versions of this model; then, based on the association records between the ECU and the supplier under this configuration entry (such as the "ACSUP1" and "EMSSUP1" identifiers in the SD tag), it extracts the actual supplier corresponding to each first control unit, i.e., the "first supplier" (such as ACECU corresponding to SUP1 supplier, EMSECU corresponding to SUP1 supplier); finally, it clarifies the one-to-one correspondence between "first control unit - first supplier", preparing for the subsequent accurate matching and loading of Basic_DiagData (basic diagnostic data) and Child_DiagData_SupName (dedicated diagnostic data) from the cache data.

[0085] S603, first diagnostic data is obtained based on the first basic diagnostic data corresponding to each first control unit and the first dedicated diagnostic data corresponding to the first supplier.

[0086] In this embodiment, for each first control unit (ECU) actually installed in the vehicle to be diagnosed, its corresponding basic diagnostic data (first basic diagnostic data, i.e., Basic_DiagData) and the exclusive diagnostic data (first exclusive diagnostic data, i.e., Child_DiagData_SupName) of the first supplier to which the ECU belongs are fused into modules according to a unified structure. After the fused data of all ECUs are integrated, a unique "first diagnostic data" (complete vehicle diagnostic data) is formed for the vehicle to be diagnosed, providing the final data support for directly carrying out diagnostic operations.

[0087] In the above method, the first control unit and its corresponding first supplier actually installed in the vehicle to be diagnosed are first selected based on the configuration information of the first vehicle model. Then, the first basic diagnostic data of each first control unit and the first exclusive diagnostic data of the corresponding supplier are extracted from the cache. Finally, the two types of data are merged to obtain the first diagnostic data. Its beneficial effect is that only the diagnostic data actually required by the vehicle is loaded, avoiding redundant data processing. At the same time, the parsed data in the cache is reused, and there is no need to repeatedly parse the huge file, which greatly improves the efficiency of diagnostic data combination and diagnostic accuracy.

[0088] In one embodiment, see Figure 7 This is a flowchart illustrating the process of determining the first diagnostic data provided in an embodiment of this application. Figure 2 ,like Figure 7 As shown, step S603 includes: S701, the first basic diagnostic data corresponding to a first control unit and the first dedicated diagnostic data corresponding to a first supplier are spliced ​​together to obtain the first sub-diagnostic data.

[0089] In this embodiment, for each first control unit (ECU) actually installed in the vehicle to be diagnosed, the first basic diagnostic data (common diagnostic data common to all suppliers) corresponding to the ECU and the first exclusive diagnostic data (personalized diagnostic data unique to the supplier) of the first supplier to which the ECU belongs are modularly spliced ​​and merged according to a unified data structure to form the "first sub-diagnostic data" unique to the control unit, which provides a basic unit for subsequent integration of vehicle diagnostic data.

[0090] For example, after the diagnostic software identifies a first control unit (such as ACECU) and its corresponding first supplier (such as SUP1), it first extracts the first basic diagnostic data (Basic_DiagData) of the ECU from the decrypted diagnostic cache data. This data includes general communication data, standard fault codes, unified menus, and basic data elements at the ODX level, as well as general menus at the OTX level and advanced functions corresponding to the Basic_AdvancedFunc.dll interface. Then, it extracts the first dedicated diagnostic data (Child_DiagData_SUP1) corresponding to the first supplier. This data includes supplier-specific fault codes, extended services, and personalized menus at the ODX level, as well as dedicated functions at the OTX level. The menu and the ChildSupName_AdvancedFunc.dll interface correspond to unique advanced functions; since the two types of data structures are completely consistent (both are classified according to ODX and OTX, and include modules such as communication data, diagnostic data, menus, and advanced functions), the software is spliced ​​and integrated module by module - general communication data and dedicated communication data complement each other, standard fault codes and specific fault codes are merged, unified menus and personalized menus are integrated, and general advanced functions and dedicated advanced functions are associated, ultimately forming the first sub-diagnostic data of the first control unit (such as AC_DiagData of ACECU). This data contains both basic general diagnostic capabilities and supplier-specific diagnostic features, which can directly support the diagnostic operations of the ECU.

[0091] S702, the first sub-diagnostic data corresponding to each of the first control units is determined as the first diagnostic data.

[0092] In this embodiment, the first sub-diagnostic data (complete diagnostic data of a single ECU) obtained by splicing and merging each first control unit (ECU) actually installed in the vehicle to be diagnosed is all summarized and integrated, and finally determined as the "first diagnostic data" of the vehicle to be diagnosed (i.e. complete diagnostic data exclusive to the whole vehicle), providing direct and usable final data support for the diagnostic software to perform a full set of diagnostic operations.

[0093] For example, after the diagnostic software generates the first sub-diagnostic data for each first control unit, it summarizes and integrates all sub-diagnostic data according to the vehicle diagnostic logic: it extracts the first sub-diagnostic data corresponding to each first control unit (such as AC_DiagData for ACECU, EMS_DiagData for EMSECU, etc.). These sub-diagnostic data are formed by splicing "basic diagnostic data + exclusive diagnostic data", including the complete communication data, diagnostic data (standard + exclusive fault codes), menus (unified + personalized), and advanced function interfaces (general + supplier-specific DLLs) of the corresponding ECU. Then, according to the vehicle ECU architecture, the software integrates and sorts all the first sub-diagnostic data in a preset order (such as powertrain system, body system, chassis system, etc.) to form structured vehicle first diagnostic data (Vehicle_DiagData). This data only contains the ECU diagnostic information of the current vehicle configuration and has no redundant data. Finally, the diagnostic software loads this first diagnostic data to perform a full set of diagnostic operations such as fault detection, functional testing, and data reading, achieving efficient and accurate diagnosis.

[0094] In the above method, the first basic diagnostic data (including common data such as public communication and standard fault codes) of each first control unit is concatenated with the first dedicated diagnostic data (including personalized data such as unique fault codes and extended services) of the corresponding first supplier to generate the first sub-diagnostic data. Then, all the first sub-diagnostic data are summarized to obtain the first diagnostic data. Its beneficial effect is to achieve accurate combination of diagnostic data, integrate only the ECU data actually required by the vehicle, avoid redundant data processing, and reuse the basic and dedicated data that have been parsed in the cache without having to repeatedly parse huge files, which greatly improves the efficiency of diagnostic data generation and diagnostic accuracy.

[0095] S604, execute the first diagnostic data to diagnose the vehicle machine to be diagnosed.

[0096] In this embodiment, after obtaining the "first diagnostic data" (complete vehicle diagnostic data) specific to the vehicle to be diagnosed by dynamically combining cached data, the diagnostic software directly calls the data to perform a full set of diagnostic operations such as fault detection, functional testing, and data reading, and finally completes the accurate diagnosis of the vehicle to be diagnosed, achieving the goal of efficient and fast diagnosis.

[0097] See Figure 8 This is a schematic diagram of the vehicle data structure after parsing the diagnostic data packet provided in the embodiments of this application, as shown below. Figure 8As shown, "Vehicle" is the top-level container, which contains multiple control units (ECUs) actually installed in the vehicle, such as "Ecu1, Ecu2...EcuN". Each ECU stores "Basic_DiagData" and "Child_DiagData_SUP1, Child_DiagData_SUP2...Child_DiagData_SUPN" (multiple supplier-specific diagnostic data). The "Basic_DiagData" folder stores common diagnostic data for the corresponding ECU (including communication parameters, standard fault codes, general menus, and common advanced function interfaces, derived from BV files, -c / -cs communication parameter files, and common OTX file parsing), adapting to the general diagnostic needs of all suppliers. The "Child_DiagData_SUPx" folder stores supplier-specific diagnostic data (including supplier-specific fault codes, extended services, personalized menus, and exclusive advanced function interfaces, derived from the corresponding EV files and supplier-specific OTX file parsing), adapting to the technical differences between different suppliers. The overall structure, through a layered design of "vehicle-ECU-data type," achieves the separate storage of basic data and exclusive data, avoiding data redundancy and enabling rapid matching of the ECU and corresponding supplier based on the actual vehicle configuration code during subsequent diagnostics, dynamically combining complete vehicle diagnostic data to support efficient and accurate diagnosis.

[0098] In the above method, the unique vehicle configuration code of the vehicle to be diagnosed is read by the diagnostic equipment and used as the core index for data matching. If the diagnostic cache data of the vehicle is already stored locally (the cache covers a set of diagnostic data corresponding to all configurations of the vehicle model), the first vehicle configuration information that matches the actual configuration of the current vehicle is filtered out from the cache based on the vehicle configuration code. Then, based on the first vehicle configuration information, the first diagnostic data specific to the vehicle is determined from the cache. Finally, the first diagnostic data is executed to complete the vehicle diagnosis. In this solution, the diagnostic resources corresponding to the actual configuration of the vehicle are directly located through the vehicle configuration code, without loading the diagnostic data of all redundant configurations of the vehicle model (such as excluding diagnostic data that is only available for other sub-models), reducing the amount of data processing, shortening the diagnostic data combination time, and improving diagnostic efficiency.

[0099] See Figure 9 This is a schematic diagram illustrating an example of the basic diagnostic data structure provided in an embodiment of this application, such as... Figure 9As shown, the structure includes two core modules: "ODX" and "OTX". The "ODX" module is further divided into communication_data, diagnostic_data, menu, and others. The "OTX" module includes menu and advanced_functions. The `communication_data` module stores the communication protocol, device address, and transmission parameters of the corresponding control unit (ECU), ensuring a stable communication connection between the diagnostic device and the ECU. `diagnostic_data` stores common diagnostic information such as standard fault codes (DTCs), basic diagnostic services, and general data elements, supporting basic fault detection and data retrieval. `menus` (under the ODX and OTX modules) provides a unified basic operation menu and an interactive menu adapted for advanced functions, ensuring the standardization and convenience of diagnostic operations. `advanced_functions` (under the OTX module) corresponds to the DLL file call interface compiled from the common OTX file, supporting the execution of basic and advanced diagnostic functions (such as general component testing). `others` serves as an auxiliary module, storing scattered common data not covered by the above modules. The overall structure, through the combination of "ODX basic data + OTX advanced functions," provides a unified basic diagnostic data foundation for ECUs from different suppliers, supporting rapid integration with supplier-specific data (Child_DiagData).

[0100] See Figure 10 This is an example diagram of the supplier-specific diagnostic data structure provided in the embodiments of this application, such as... Figure 10 As shown, the structure is based on "Child_DiagData_SUP1" as the core container, and is divided into two major modules "ODX" and "OTX" according to data type. The "ODX" module contains communication_data, diagnostic_data, menu, and others, while the "OTX" module contains menu and ChildSupName_advanced_functions.

[0101] The `communication_data` module stores the specific communication parameters of the corresponding control unit (ECU) under the supplier's adaptation (such as supplier-specific transmission adaptation information, supplementing basic communication data) to ensure accurate communication between the diagnostic equipment and the ECU. `diagnostic_data` stores supplier-specific fault codes, extended diagnostic services, and other personalized diagnostic information to support differentiated fault detection needs. `menus` (under the ODX and OTX modules) provides supplier-customized basic operation menus and interactive menus for exclusive advanced functions, optimizing diagnostic operation compatibility. `ChildSupName_advanced_functions` corresponds to the DLL file call interface compiled from the supplier's exclusive OTX file, supporting the execution of supplier-specific advanced diagnostic functions (such as exclusive component testing and customized system calibration). `others` serves as an auxiliary module, storing scattered supplier-specific data not covered by the above modules. The overall structure, through a module design consistent with the basic diagnostic data (`Basic_DiagData`), enables rapid integration with the basic data, providing the vehicle to be diagnosed with complete diagnostic capabilities adapted to a specific supplier.

[0102] See Figure 11 This is an example diagram of the real vehicle data structure formed after dynamically trimming diagnostic data according to the embodiments of this application, such as... Figure 11 As shown, the structure uses "Vehicle_DiagData (vehicle diagnostic data)" as the top-level core container, which contains multiple dedicated diagnostic data of the actual control units (ECUs) installed in the vehicle to be diagnosed, such as "Ecu1_DiagData, Ecu2_DiagData...EcuN_DiagData". The diagnostic data of each ECU is composed of "Basic_DiagData (basic diagnostic data)" and the corresponding supplier's "Child_DiagData_SUPx (supplier-specific diagnostic data)".

[0103] The "Basic_DiagData" database provides the general diagnostic foundation for the corresponding ECU (including common communication parameters, standard fault codes, unified menus, etc.), while the "Child_DiagData_SUPx" database supplements the personalized diagnostic capabilities of the actual ECU supplier (including unique fault codes, extended services, dedicated advanced function interfaces, etc.). The overall structure, through a hierarchical design of "vehicle-ECU-basic + dedicated data," achieves precise tailoring and integration of the vehicle's actual configuration diagnostic data, ultimately forming "first diagnostic data" containing only the diagnostic resources truly needed by the vehicle. This data is directly used for subsequent efficient execution of fault detection, functional testing, and other diagnostic operations, avoiding redundant data from affecting diagnostic efficiency. See Figure 12This is a schematic diagram of the initial diagnostic process structure provided in the embodiments of this application, as shown below. Figure 12 As shown, it includes: 1. Initiate initial diagnostics and read the vehicle configuration code (VehicleCode): The diagnostic process officially begins. The diagnostic equipment (VCI) reads the VehicleCode (a string of hexadecimal characters defined by the manufacturer, uniquely identifying the vehicle model, year, and sub-model configuration, such as "001F2024030200" representing the 2024 Mercedes-Benz E300L Luxury model) through the vehicle's OBD interface or dedicated communication protocol, which serves as the core index for subsequent data matching.

[0104] 2. Check if diagnostic cache data exists locally: Based on the read VehicleCode, the diagnostic software queries the local preset storage area to determine whether diagnostic cache data (including Vehicle_Config, Basic_DiagData, Child_DiagData, etc.) corresponding to this vehicle model has been stored. Since this is the first diagnostic, there is no cache data locally, and the process proceeds to the next step.

[0105] 3. Download the complete diagnostic data package: The diagnostic software downloads the complete diagnostic data package corresponding to the vehicle model from the server via the network. The data package includes the V file (vehicle configuration mapping), BV file (basic supplier data), EV file (extended supplier-specific data), -c / -cs file (communication parameters), and OTX file (advanced diagnostic functions). After downloading, it is temporarily saved locally.

[0106] 4. Parse the V file to generate Vehicle_Config: First, parse the V file in the data package, extract the configuration information of different sub-models distinguished by SDG tags (each SDG tag corresponds to a sub-model, including the ECU list of that sub-model and the association between the ECU and the supplier), and organize it into a structured "Vehicle_Config (vehicle configuration data)", which clarifies the ECU and supplier mapping rules for all configuration versions of this model.

[0107] 5. Parse basic data of each ECU and store it in Basic_DiagData: Parse the BV file and -c / -cs file in the data package according to the ECU dimension: Extract the ECU's communication parameters (such as communication protocol, device address, transmission parameters) from the -c / -cs file, and extract common diagnostic data (such as standard fault codes, basic diagnostic services, unified menu) common to all suppliers from the BV file. Integrate the two types of data and store them in "Basic_DiagData (Basic Diagnostic Data)". Each ECU corresponds to a dedicated Basic_DiagData.

[0108] 6. Parse OTX files to generate Basic_AdvancedFunc.dll: Parse public OTX files containing the word "Basic" in the data package, compile them into a directly callable "Basic_AdvancedFunc.dll" dynamic link library file, and at the same time supplement the calling interface information of the dll file into the corresponding ECU's Basic_DiagData to improve the advanced function support of basic diagnostic data.

[0109] 7. Parse EV files and store them in Child_DiagData: Parse the EV files from different suppliers in the data package one by one (named by "ECU name + supplier abbreviation", such as "AC_EV_SUP1"), extract the supplier-specific diagnostic data (such as specific fault codes, extended diagnostic services, personalized menus) from each EV file, and store the parsing results according to the naming rule "Child_DiagData_SupName" (SupName is the supplier abbreviation, such as "Child_DiagData_SUP1") to form the exclusive diagnostic data for each supplier.

[0110] 8. Encrypt and save cached data: The Vehicle_Config, Basic_DiagData of all ECUs, and Child_DiagData of each supplier generated above are encrypted according to a preset format (such as json, xml or database format) and stored in a preset area on the local machine of the diagnostic device to form the diagnostic cache data of the vehicle model, which avoids data leakage and facilitates subsequent retrieval.

[0111] 9. Combine diagnostic data and perform vehicle diagnostics: Based on the matching relationship between the current vehicle's ECU and the supplier in Vehicle_Config, the Basic_DiagData of the corresponding ECU and the Child_DiagData of the dedicated supplier are spliced ​​and merged by module (such as general communication data + dedicated communication data, standard fault codes + specific fault codes) to form complete vehicle diagnostic data. The diagnostic software calls this data to perform diagnostic operations such as fault detection and functional testing to complete the initial diagnosis.

[0112] See Figure 13 This is a schematic diagram of the subsequent diagnostic process structure provided in the embodiments of this application, such as... Figure 13 As shown, it includes: 1. Initiate subsequent diagnostics and read the vehicle configuration code (VehicleCode): The diagnostic process is initiated. The diagnostic equipment (VCI) reads the VehicleCode (a hexadecimal string that uniquely identifies the vehicle model, year, and sub-model configuration) of the vehicle to be diagnosed through the vehicle's OBD interface or dedicated communication protocol, which serves as the core index for subsequent data matching.

[0113] 2. Check if corresponding diagnostic cache data exists locally: Based on the read VehicleCode, the diagnostic software queries the local preset storage area (dedicated folders categorized by vehicle model) to determine if the encrypted diagnostic cache data (including Vehicle_Config, Basic_DiagData, and Child_DiagData) for that vehicle model has been stored. Since this is a subsequent diagnostic, the cache data already exists locally, and the process proceeds to the next step.

[0114] 3. Decrypt local cache data: The diagnostic software decrypts the encrypted cache data of this vehicle model stored locally, unlocking Vehicle_Config (vehicle configuration mapping data), Basic_DiagData (basic diagnostic data) of each ECU, and Child_DiagData (specific diagnostic data) of each supplier, in preparation for data extraction.

[0115] 4. Obtain the actual vehicle configuration information from Vehicle_Config: Parse the decrypted Vehicle_Config data, filter out the matching sub-model configuration entries based on the current vehicle's VehicleCode, accurately identify the list of ECUs (i.e., the first control unit) actually installed in the vehicle to be diagnosed, and the actual supplier (i.e., the first supplier) corresponding to each ECU.

[0116] 5. Load the basic diagnostic data (Basic_DiagData) of the corresponding ECU: Based on the identified list of actual ECUs, extract the basic_DiagData of each ECU from the decrypted cache data. This data contains the ECU's common communication parameters, standard fault codes, unified menus and general advanced function interfaces, which is the basic data foundation for diagnosis.

[0117] 6. Load the corresponding supplier's exclusive diagnostic data (Child_DiagData): Combine the first supplier corresponding to each ECU, extract the corresponding Child_DiagData (named in the format of "Child_DiagData_SupName", where SupName is the supplier's abbreviation) from the cache data. This data contains supplier-specific fault codes, extended diagnostic services, personalized menus, and exclusive advanced function interfaces.

[0118] 7. Dynamically combine to form vehicle diagnostic data: Since the Basic_DiagData and Child_DiagData data structures are completely identical (both contain communication data, diagnostic data, menus, and advanced function interface modules), the software splices and merges the Basic_DiagData of each ECU with the Child_DiagData of the corresponding supplier one by one according to the module to form the complete sub-diagnostic data of each ECU. Then, it summarizes the sub-diagnostic data of all ECUs to obtain the exclusive vehicle diagnostic data of the vehicle to be diagnosed.

[0119] 8. Perform quick diagnostic operations: The diagnostic software calls up the combined vehicle diagnostic data, establishes a stable connection with the ECU based on the communication parameters in the data, and performs diagnostic operations such as fault detection (reading standard + specific fault codes), data reading (obtaining real-time parameters of the ECU), and functional testing (calling general + specific advanced functions) to complete vehicle diagnosis.

[0120] 9. Update cached data access time: After the diagnosis is completed, the software updates the access time of the local cached data, marking the cached data as still valid, so that it can be called first when diagnosing the same model in the future, and at the same time provides a time basis for the cache clearing mechanism (such as deleting cache that has not been used for a long time).

[0121] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0122] Corresponding to the vehicle dynamic diagnosis method based on cached data in the above embodiment, Figure 14 This is a structural block diagram of a vehicle dynamic diagnostic device based on cached data provided in the embodiments of this application. For ease of explanation, only the parts related to the embodiments of this application are shown.

[0123] Reference Figure 14 The device includes: Data preprocessing module 141 is used for: For each control unit corresponding to the same vehicle model, store the public diagnostic data of all suppliers corresponding to the control unit in the first preset file; The dedicated diagnostic data for each supplier corresponding to the control unit is stored in a second preset file corresponding to each supplier.

[0124] Optionally, the data preprocessing module 141 is also used for: Set up a vehicle configuration table; the vehicle configuration table contains a version configuration list for all vehicle versions corresponding to the vehicle model; each version configuration list contains all control units corresponding to the vehicle version, the supplier for each control unit, and the second preset file for each supplier; Store the vehicle configuration table in a third preset file; A diagnostic data package corresponding to each vehicle model is constructed based on the first preset file, the second preset file, the third preset file, and the communication parameter file corresponding to the control unit.

[0125] The vehicle dynamic diagnostic device 14 based on cached data also includes: Data caching module 142 is used for: If the diagnostic cache data of the vehicle to be diagnosed is not stored locally, download the corresponding diagnostic data package of the vehicle to be diagnosed according to the vehicle configuration code; The diagnostic data package contains multiple files, which are then parsed to obtain the parsed data. The parsed data is stored in a local preset area to obtain diagnostic cache data; Diagnose the data to be diagnosed based on cached data.

[0126] Optionally, the data caching module 142 is also used for: The third preset file in the diagnostic data package is parsed to obtain a version configuration list of all configurations of the vehicle to be diagnosed. Parse the first preset file corresponding to each control unit in the diagnostic data package to obtain the basic diagnostic data corresponding to each preset file; Parse multiple second-preset files in the diagnostic data package to obtain the unique diagnostic data for each vendor; The vehicle dynamic diagnostic device 14 based on cached data includes: The vehicle model acquisition module 143 is used to acquire the vehicle model configuration code corresponding to the vehicle to be diagnosed; wherein, the vehicle model configuration code is used to represent the vehicle model version and configuration information of the vehicle to be diagnosed. The vehicle configuration information acquisition module 144 is used to obtain the first vehicle configuration information corresponding to the vehicle to be diagnosed from the diagnostic cache data according to the vehicle configuration code when the diagnostic cache data of the vehicle to be diagnosed is stored locally; wherein, the diagnostic cache data is used to represent the complete set of diagnostic data of the vehicle to be diagnosed; The diagnostic data determination module 145 is used to determine the first diagnostic data of the vehicle to be diagnosed from the diagnostic cache data based on the first vehicle configuration information. The vehicle diagnostic module 146 is used to execute first diagnostic data to diagnose the vehicle to be diagnosed.

[0127] Optionally, the diagnostic data determination module 145 is also used for: Based on the configuration information of the first vehicle model, determine at least one first control unit corresponding to the vehicle to be diagnosed and the first supplier corresponding to each first control unit; Obtain the first basic diagnostic data corresponding to each first control unit and the first dedicated diagnostic data corresponding to the first supplier from the diagnostic cache data; The first diagnostic data is obtained based on the first basic diagnostic data corresponding to each first control unit and the first dedicated diagnostic data corresponding to the first supplier.

[0128] Optionally, the diagnostic data determination module 145 is also used for: The first basic diagnostic data corresponding to a first control unit and the first dedicated diagnostic data corresponding to a first supplier are concatenated to obtain the first sub-diagnostic data; The first sub-diagnostic data corresponding to each of the first control units is determined as the first diagnostic data.

[0129] The version configuration list, multiple basic diagnostic data, and multiple exclusive diagnostic data are recorded as parsed data.

[0130] It should be noted that the information interaction and execution process between the above-mentioned devices / units are based on the same concept as the method embodiments of this application. For details on their specific functions and technical effects, please refer to the method embodiments section, and they will not be repeated here.

[0131] in addition, Figure 14 The vehicle dynamic diagnostic device based on cached data shown can be a software unit, a hardware unit, or a combination of software and hardware built into existing terminal equipment. It can also be integrated into the terminal equipment as an independent component or exist as a standalone terminal equipment.

[0132] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is merely an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiments can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit. Furthermore, the specific names of the functional units and modules are only for easy differentiation and are not intended to limit the scope of protection of this application. The specific working process of the units and modules in the above system can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0133] Figure 15 This is a schematic diagram of the structure of the terminal device provided in the embodiments of this application. For example... Figure 15 As shown, the terminal device 15 of this embodiment includes: at least one processor 150 ( Figure 15 (Only one is shown in the image) a processor, a memory 151, and a computer program 152 stored in the memory 151 and executable on at least one processor 150. When the processor 150 executes the computer program 152, it implements the steps in any of the above embodiments of the vehicle dynamic diagnostic method based on cached data.

[0134] The terminal device can be a computing device such as a desktop computer, laptop, handheld computer, or cloud server. This terminal device may include, but is not limited to, a processor and memory. Those skilled in the art will understand that... Figure 15 This is merely an example of terminal device 15 and does not constitute a limitation on terminal device 15. It may include more or fewer components than shown, or combine certain components, or different components, such as input / output devices, network access devices, etc.

[0135] The processor 150 may be a Central Processing Unit (CPU), or it may be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor may be a microprocessor or any conventional processor.

[0136] In some embodiments, memory 151 may be an internal storage unit of terminal device 15, such as a hard disk or memory of terminal device 15. In other embodiments, memory 151 may be an external storage device of terminal device 15, such as a plug-in hard disk, smart media card (SMC), secure digital card (SD), flash card, etc., equipped on terminal device 15. Furthermore, memory 151 may include both internal and external storage units of terminal device 15. Memory 151 is used to store operating system, applications, bootloader, data, and other programs, such as program code of computer programs. Memory 151 may also be used to temporarily store data that has been output or will be output.

[0137] This application also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, can implement the steps in the above-described method embodiments.

[0138] This application provides a computer program product that, when run on a terminal device, enables the terminal device to implement the steps described in the various method embodiments above.

[0139] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, all or part of the processes in the methods of the above embodiments of this application can be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. A computer-readable medium can include at least: any entity or device capable of carrying computer program code to a device / terminal device, a recording medium, a computer memory, a read-only memory (ROM), a random access memory (RAM), an electrical carrier signal, a telecommunication signal, and a software distribution medium. Examples include USB flash drives, portable hard drives, magnetic disks, or optical disks. In some jurisdictions, according to legislation and patent practice, computer-readable media cannot be electrical carrier signals or telecommunication signals.

[0140] In the above embodiments, the descriptions of each embodiment have different focuses. For parts that are not described in detail or recorded in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0141] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

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

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

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

Claims

1. A vehicle dynamic diagnostic method based on cached data, characterized in that, The method includes: Obtain the vehicle model configuration code corresponding to the vehicle to be diagnosed; wherein, the vehicle model configuration code is used to represent the vehicle model version and configuration information of the vehicle to be diagnosed; When the diagnostic cache data of the vehicle to be diagnosed is stored locally, the first vehicle configuration information corresponding to the vehicle to be diagnosed is obtained from the diagnostic cache data according to the vehicle configuration code; wherein, the diagnostic cache data is used to represent the diagnostic data set corresponding to all configurations of the vehicle to be diagnosed; The first diagnostic data of the vehicle to be diagnosed is determined from the diagnostic cache data based on the first vehicle configuration information; The first diagnostic data is executed to diagnose the vehicle to be diagnosed.

2. The vehicle dynamic diagnosis method based on cached data as described in claim 1, characterized in that, The step of determining the first diagnostic data of the vehicle to be diagnosed from the diagnostic cache data based on the first vehicle configuration information includes: Based on the first vehicle configuration information, at least one first control unit corresponding to the vehicle to be diagnosed and a first supplier corresponding to each first control unit are determined. Obtain the first basic diagnostic data corresponding to each of the first control units and the first dedicated diagnostic data corresponding to the first supplier from the diagnostic cache data; The first diagnostic data is obtained based on the first basic diagnostic data corresponding to each of the first control units and the first dedicated diagnostic data corresponding to the first supplier.

3. The vehicle dynamic diagnosis method based on cached data as described in claim 2, characterized in that, The step of obtaining the first diagnostic data based on the first basic diagnostic data corresponding to each first control unit and the first dedicated diagnostic data corresponding to the first supplier includes: The first basic diagnostic data corresponding to one of the first control units and the first dedicated diagnostic data corresponding to the first supplier are concatenated to obtain the first sub-diagnostic data; The first sub-diagnostic data corresponding to each of the first control units is determined as the first diagnostic data.

4. The vehicle dynamic diagnosis method based on cached data as described in claim 1, characterized in that, Before diagnosing the vehicle to be diagnosed, the method further includes: For each control unit corresponding to the same vehicle model, the public diagnostic data of all suppliers corresponding to the control unit are stored in a first preset file; The dedicated diagnostic data of each supplier corresponding to the control unit is stored in a second preset file corresponding to each supplier.

5. The vehicle dynamic diagnosis method based on cached data as described in claim 4, characterized in that, The method further includes: A vehicle configuration table is set up; wherein the vehicle configuration table contains a version configuration list of all vehicle versions corresponding to the vehicle model; wherein each version configuration list contains all control units corresponding to the vehicle version, the supplier corresponding to each control unit, and the second preset file corresponding to each supplier; Store the vehicle configuration table in a third preset file; A diagnostic data package corresponding to each vehicle model is constructed based on the first preset file, the second preset file, the third preset file, and the communication parameter file corresponding to the control unit.

6. The vehicle dynamic diagnosis method based on cached data as described in claim 5, characterized in that, The method further includes: If the diagnostic cache data of the vehicle to be diagnosed is not stored locally, the diagnostic data package corresponding to the vehicle to be diagnosed is downloaded according to the vehicle configuration code; The diagnostic data packet contains multiple files, which are then parsed to obtain parsed data. The parsed data is stored in a local preset area to obtain the diagnostic cache data; The data to be diagnosed is diagnosed based on the cached data.

7. The vehicle dynamic diagnosis method based on cached data as described in claim 6, characterized in that, The process of parsing multiple files contained in the diagnostic data packet to obtain parsed data includes: The third preset file in the diagnostic data packet is parsed to obtain a version configuration list of all configurations of the vehicle to be diagnosed; Parse the first preset file corresponding to each control unit in the diagnostic data packet to obtain the basic diagnostic data corresponding to each preset file; Parse multiple second preset files in the diagnostic data packet to obtain unique diagnostic data for each supplier; The version configuration list, the multiple sets of basic diagnostic data, and the multiple sets of specific diagnostic data are referred to as the parsed data.

8. A vehicle dynamic diagnostic device based on cached data, characterized in that, include: The vehicle model acquisition module is used to acquire the vehicle model configuration code corresponding to the vehicle to be diagnosed; wherein, the vehicle model configuration code is used to represent the vehicle model and configuration information of the vehicle to be diagnosed; The vehicle configuration information acquisition module is used to retrieve the first vehicle configuration information corresponding to the vehicle to be diagnosed from the diagnostic cache data according to the vehicle configuration code, when the diagnostic cache data of the vehicle to be diagnosed is stored locally; wherein, the diagnostic cache data is used to represent the complete diagnostic data set of the vehicle to be diagnosed; A diagnostic data determination module is used to determine the first diagnostic data of the vehicle to be diagnosed from the diagnostic cache data based on the first vehicle configuration information. The vehicle diagnostic module is used to execute the first diagnostic data to diagnose the vehicle to be diagnosed.

9. A terminal device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the method as described in any one of claims 1 to 7.

10. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it implements the method as described in any one of claims 1 to 7.

Images