A method, apparatus, device and medium for automatically synchronizing a diagnostic description file

Abstract

This application provides a method, apparatus, device, and medium for automatic synchronization of diagnostic description files, relating to the field of vehicle diagnostic technology. The method includes: parsing a diagnostic specification file to obtain a first diagnostic data model; parsing a diagnostic description file to obtain a second diagnostic data model; comparing the differences between diagnostic objects in the first and second diagnostic data models to obtain a difference list; and modifying diagnostic instances in the diagnostic description file based on the difference list, retaining the reference attributes of the diagnostic instances, replacing the proprietary identifier attributes of the diagnostic instances with new identifiers, and obtaining a modified diagnostic description file. This modified diagnostic description file is used for automatic synchronization between diagnostic specification files and diagnostic description files of different formats, while maintaining the integrity of the references to diagnostic instances in the diagnostic description file.

Description

Technical Field

[0001] This application relates to the field of vehicle diagnostic technology, and more specifically, to a method, apparatus, device, and medium for automatically synchronizing diagnostic description files. Background Technology

[0002] In the field of vehicle diagnostics, the diagnostic functions of electronic control units (ECUs) are typically defined by diagnostic description files. Diagnostic requirements specifications are maintained by vehicle manufacturers and record the diagnostic requirements needed for vehicle off-line testing. During mass production, diagnostic requirements change frequently, necessitating the synchronization of the diagnostic requirements specifications with the diagnostic description files to ensure consistency.

[0003] In related technologies, the synchronization between diagnostic requirements specifications and diagnostic description files primarily relies on manual modification. This manual approach requires comparing each diagnostic object and its attributes in both files, which is inefficient and prone to errors, failing to meet the demands of frequent changes in diagnostic requirements during mass production. Another approach is to regenerate the diagnostic description file, starting from the diagnostic requirements specifications. However, a full regeneration overwrites existing, manually verified configurations within the diagnostic description file, and the file contains numerous references between diagnostic instances. A full regeneration cannot preserve these references, causing the generated file to fail to load correctly by diagnostic tools.

[0004] The diagnostic requirements specification document and the diagnostic description document have different file formats, making cross-format synchronization difficult. If the reference attribute of a diagnostic instance in the diagnostic description document is corrupted, the file will fail to load. Summary of the Invention

[0005] The problem addressed in this application is how to automatically synchronize diagnostic specification files and diagnostic description files of different formats, while maintaining the integrity of the references to diagnostic instances in the diagnostic description files.

[0006] To address the aforementioned issues, this application provides a method, apparatus, device, and medium for automatically synchronizing diagnostic description files.

[0007] Firstly, this application provides a method for automatically synchronizing diagnostic description files, including: Parse the diagnostic specification document to obtain a first diagnostic data model, which includes diagnostic data organized by diagnostic object type; Parse the diagnostic description file to obtain a second diagnostic data model. The second diagnostic data model includes diagnostic instances, and the attributes of the diagnostic instances include reference attributes and proprietary identifier attributes. Compare the diagnostic objects in the first diagnostic data model and the second diagnostic data model to obtain a list of differences; Based on the difference list, the diagnostic instances in the diagnostic description file are modified, retaining the reference attribute of the diagnostic instance and replacing the own identifier attribute of the diagnostic instance with a new identifier to obtain the modified diagnostic description file.

[0008] Optionally, the diagnostic specification document includes multiple worksheets, each worksheet recording diagnostic data, and the multiple worksheets are associated with each other through a diagnostic object identifier; parsing the diagnostic specification document to obtain the first diagnostic data model includes: Determine the parsing path corresponding to the diagnostic object type; Following the parsing path, extract diagnostic attribute data of the diagnostic object type from the corresponding worksheet, associate the diagnostic attribute data with the diagnostic object identifier, and obtain the structured record corresponding to the diagnostic object type. The structured records are integrated to obtain the first diagnostic data model.

[0009] Optionally, the diagnostic object type includes fault codes; the step of extracting diagnostic attribute data of the diagnostic object type from the corresponding worksheet according to the parsing path, and associating the diagnostic attribute data based on the diagnostic object identifier to obtain the structured record corresponding to the diagnostic object type includes: Extract the attribute data of each fault code from the fault code worksheet; Extract the first correspondence between each fault code and the snapshot group number from the snapshot worksheet; Extract the second correspondence between each snapshot group number and the set of data identifiers from the snapshot data identifier worksheet; Based on the first correspondence and the second correspondence, the data identifier sets of the snapshot group numbers corresponding to each fault code are merged through a set union operation to obtain a list of snapshot data identifiers corresponding to each fault code; Based on the attribute data of each fault code and the snapshot data identifier list, a structured record corresponding to each fault code is obtained.

[0010] Optionally, the step of parsing the diagnostic description file to obtain the second diagnostic data model includes: Extract the identifier and byte length of the data elements in the diagnostic description file, and establish a first mapping relationship between the identifier and the byte length of the data elements; Extract the data identifier and reference information of the data identifier element in the diagnostic description file, and establish a second mapping relationship between the data identifier and the reference information, wherein the reference information points to the identifier of the data element; Extract the attributes of the diagnostic instances in the diagnostic classification container of the diagnostic description file, and determine the byte length of the diagnostic instance based on the data identifier associated with the diagnostic instance, the second mapping relationship, and the first mapping relationship; The second diagnostic data model is constructed based on the attributes of the diagnostic instance and the byte length.

[0011] Optionally, extracting the attributes of the diagnostic instances in the diagnostic classification container of the diagnostic description file includes: The category name of the diagnostic category container is determined based on the text content of the name element within the diagnostic category container. Static value attributes and name attributes are extracted from the diagnostic classification container, and the service type is determined by text matching. The attributes of the diagnostic instance include the static value attributes, the name attributes, and the service type.

[0012] Optionally, before comparing the differences between the diagnostic objects in the first diagnostic data model and the second diagnostic data model, the method further includes: Based on the service sub-function combination of the diagnostic object in the diagnostic specification document, the diagnostic classification of the diagnostic object is inferred according to the preset unified diagnostic service semantic rules, and the diagnostic classification is used as the comparison benchmark for the diagnostic classification dimension in the difference comparison. The difference comparison includes comparing at least one of the following: identifier, name, byte length, service sub-function, session, and security level of the diagnostic object.

[0013] Optionally, modifying the diagnostic instance in the diagnostic description file includes: Select diagnostic instances that meet the preset service coverage conditions from the diagnostic classification container as template diagnostic instances; Clone the template diagnostic instance to generate a new diagnostic instance; The new diagnostic instance is written into the diagnostic classification container to obtain the modified diagnostic description file.

[0014] Optionally, the method further includes performing at least one of the following editing operations based on the difference list: Delete the instance block of the diagnostic instance corresponding to the diagnostic object to be deleted indicated by the difference list; Replace the instance block of the diagnostic instance corresponding to the diagnostic object to be replaced indicated by the difference list with the instance block of the new diagnostic instance; For diagnostic objects with byte length changes indicated by the difference list, replace the data reference of the diagnostic object with a reference to the data object corresponding to the target byte length.

[0015] Optionally, the method further includes: The editing operations performed on the diagnostic description file are sorted in descending order of line number and applied sequentially from the bottom of the diagnostic description file upwards.

[0016] Optionally, after obtaining the modified diagnostic description file, the method further includes: The modified diagnostic description file is re-parsed, and the re-parsed diagnostic data is compared again with the diagnostic specification file. After confirming that the difference has been cleared to zero, the modified diagnostic description file is output.

[0017] Secondly, this application provides an automatic synchronization device for diagnostic description files, comprising: The first parsing module is used to parse the diagnostic specification document and obtain the first diagnostic data model, which includes diagnostic data organized according to the type of diagnostic object. The second parsing module is used to parse the diagnostic description file to obtain a second diagnostic data model. The second diagnostic data model includes diagnostic instances, and the attributes of the diagnostic instances include reference attributes and proprietary identifier attributes. The comparison module is used to compare the differences between the diagnostic objects in the first diagnostic data model and the second diagnostic data model to obtain a list of differences. The modification module is used to modify the diagnostic instances in the diagnostic description file based on the difference list, retain the reference attribute of the diagnostic instance, replace the own identifier attribute of the diagnostic instance with a new identifier, and obtain the modified diagnostic description file.

[0018] Thirdly, this application provides an electronic device, including a memory and a processor; The memory is used to store computer programs; The processor is configured to implement the automatic synchronization method for diagnostic description files as described in the first aspect when executing the computer program.

[0019] Fourthly, this application provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the automatic synchronization method for diagnostic description files as described in the first aspect.

[0020] The beneficial effects of the automatic synchronization method for diagnostic description files in this application are: By parsing the diagnostic specification document, a first diagnostic data model organized by diagnostic object type is obtained. A second diagnostic data model, containing reference attributes and unique identifier attributes, is obtained by parsing the diagnostic description document. Differences between the diagnostic objects in the two models are compared at a unified semantic level to obtain a difference list. Based on this difference list, the diagnostic description document is incrementally modified by retaining reference attributes and replacing unique identifier attributes. This constitutes a diagnostic description document synchronization scheme that maintains consistency between cross-format difference comparison and reference integrity. Changes to the diagnostic specification document are automatically reflected in the diagnostic description document. Cross-format synchronization of the two types of files is achieved while ensuring that the diagnostic description document can be loaded normally by diagnostic editing tools. This solves the problems of low efficiency and easy omissions in manual comparison and modification in related technologies, and the problem of automatic modification easily destroying reference relationships and rendering the file unusable. Attached Figure Description

[0021] Figure 1 This is a flowchart illustrating the automatic synchronization method for diagnostic description files according to an embodiment of this application. Figure 2 This is an example diagram of an electronic device according to an embodiment of this application. Detailed Implementation

[0022] To make the above-mentioned objects, features, and advantages of this application more apparent and understandable, specific embodiments of this application are described in detail below with reference to the accompanying drawings. Although some embodiments of this application are shown in the drawings, it should be understood that this application can be implemented in various forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided to provide a more thorough and complete understanding of this application. It should be understood that the accompanying drawings and embodiments of this application are for illustrative purposes only and are not intended to limit the scope of protection of this application.

[0023] It should be understood that the steps described in the method embodiments of this application may be performed in different orders and / or in parallel. Furthermore, the method embodiments may include additional steps and / or omit the steps shown. The scope of this application is not limited in this respect.

[0024] The term "comprising" and its variations as used herein are open-ended, meaning "including but not limited to"; the term "based on" means "at least partially based on"; the term "one embodiment" means "at least one embodiment"; the term "another embodiment" means "at least one additional embodiment"; the term "some embodiments" means "at least some embodiments"; and the term "optionally" means "optional embodiments". Definitions of other terms will be given in the description below. It should be noted that the concepts of "first," "second," etc., mentioned in this application are used only to distinguish different devices, modules, or units, and are not intended to limit the order of functions performed by these devices, modules, or units or their interdependencies.

[0025] It should be noted that the terms "one" and "more" used in this application are illustrative rather than restrictive, and those skilled in the art should understand that, unless otherwise expressly indicated in the context, they should be understood as "one or more".

[0026] The names of messages or information exchanged between multiple devices in the embodiments of this application are for illustrative purposes only and are not intended to limit the scope of these messages or information.

[0027] like Figure 1 As shown in the embodiment of this application, an automatic synchronization method for diagnostic description files is provided, comprising: Step S100: Parse the diagnostic specification document to obtain a first diagnostic data model, which includes diagnostic data organized according to the type of diagnostic object.

[0028] A diagnostic specification document is a document that contains definitions of diagnostic requirements, such as a System Service Description Table (SSDS) organized in spreadsheet format. A diagnostic specification document includes multiple worksheets, each defining different categories of diagnostic objects, and the worksheets are logically linked through diagnostic object identifiers.

[0029] Diagnostic object types include Data Identifiers (DIDs), Disturbance Codes (DTCs), and Routines Identifiers (RIDs), with diagnostic data for different object types scattered across different worksheets. For example, DID diagnostic data is distributed across the DID worksheet and the I / O control worksheet; DTC diagnostic data is distributed across the DTC worksheet, the snapshot worksheet, and the snapshot DID worksheet; and RID diagnostic data is distributed across the control routine worksheet. These worksheets are parsed separately, and the diagnostic data scattered across different worksheets is aggregated according to the diagnostic object identifier to obtain a structured data model organized by diagnostic object type, i.e., the first diagnostic data model.

[0030] The first diagnostic data model represents a structured collection of diagnostic data with organizational dimensions as the diagnostic object type. Each diagnostic object type contains attribute data for several diagnostic objects. Because the distribution and header structure of diagnostic data for different diagnostic object types in the worksheet are inconsistent in the diagnostic specification document, data is extracted separately according to the diagnostic object type. This avoids column name misalignment and data loss caused by direct reading, ensuring the completeness of attribute data for each type of diagnostic object.

[0031] Step S200: Parse the diagnostic description file to obtain a second diagnostic data model. The second diagnostic data model includes diagnostic instances, and the attributes of the diagnostic instances include reference attributes and proprietary identifier attributes.

[0032] A diagnostic description file is a file that contains configurations for diagnostic instances, such as a CANdela diagnostic description file (CDD) organized in markup language format. Diagnostic instances in a diagnostic description file are grouped into different containers according to diagnostic categories, and these instances are interconnected through attribute references, forming a cross-level reference network.

[0033] The attributes of a diagnostic instance can be divided into two categories: referencing attributes, which point to other objects in the diagnostic description file and are used to maintain the relationships between diagnostic instances, such as static referencing attributes, proxy referencing attributes, template referencing attributes, identifier referencing attributes, and data referencing attributes; and unique identifier attributes, which are the identifiers of the diagnostic instance itself, used to uniquely identify the diagnostic instance, such as instance identifier attributes and object identifier attributes. When parsing the diagnostic description file, the referencing attributes and unique identifier attributes of each diagnostic instance are identified and recorded to obtain the second diagnostic data model.

[0034] Since attributes such as the byte length of diagnostic instances in the diagnostic description file are indirectly expressed through reference attributes, and reference attributes and proprietary identifier attributes have similar forms in the file, the distinction between the two types of attributes is preserved, providing a basis for attribute classification for modifications. The second diagnostic data model serves as the benchmark for the diagnostic description file in subsequent difference comparisons, providing the diagnostic instances to be modified and the attribute classification of the diagnostic instances for modifications.

[0035] Step S300: Compare the diagnostic objects in the first diagnostic data model and the second diagnostic data model to obtain a list of differences.

[0036] In one embodiment, the difference comparison refers to comparing the attributes of diagnostic objects in the first diagnostic data model and those in the second diagnostic data model at the granularity of the diagnostic object, identifying inconsistencies between the two models. The difference list is a collection of inconsistent attribute items between the two diagnostic objects; each difference corresponds to one or more inconsistencies in a single diagnostic object's attributes. Since the two diagnostic objects may have multiple attribute differences under the same diagnostic object identifier, comparing at the diagnostic object granularity covers inconsistencies at various attribute levels, avoiding omissions due to merely checking the existence of the identifier. The difference list is used to enable modifications to be partially generated for inconsistencies.

[0037] Step S400: Based on the difference list, modify the diagnostic instances in the diagnostic description file, retain the reference attribute of the diagnostic instance, replace the own identifier attribute of the diagnostic instance with a new identifier, and obtain the modified diagnostic description file.

[0038] In one embodiment, the corresponding diagnostic instance in the diagnostic description file is modified according to the differences indicated by the difference list. During modification, the reference attributes of the diagnostic instance are preserved to ensure that the reference relationship between the diagnostic instance and other objects is not disrupted; the proprietary identifier attribute is replaced with a new identifier, giving the newly added or modified diagnostic instance an independent identifier. By distinguishing between the two types of attributes and processing them separately, the integrity of the references is maintained while modifying the diagnostic description file, ensuring that the modified diagnostic description file can be loaded correctly by the diagnostic tool.

[0039] The modified diagnostic description file is used to be flashed into the diagnostic configuration area of ​​the electronic control unit, so that the production line diagnostic instrument can read it and perform offline testing.

[0040] The new identifier represents the value after replacing the existing identifier attribute, and is used to identify the modified diagnostic instance without conflicting with the identifiers of existing diagnostic instances in the diagnostic description file. Because the reference attributes retain their original values ​​and the reference relationships between internal objects are intact, the modified diagnostic description file can be loaded normally by the diagnostic description file editing tool.

[0041] In this embodiment, a first diagnostic data model organized by diagnostic object type is obtained by parsing the diagnostic specification file, and a second diagnostic data model containing reference attributes and proprietary identifier attributes is obtained by parsing the diagnostic description file. Differences between the diagnostic objects in the two models are compared at a unified semantic level to obtain a difference list. Based on the difference list, the diagnostic description file is incrementally modified by retaining reference attributes and replacing proprietary identifier attributes. This constitutes a diagnostic description file synchronization scheme that maintains consistency between cross-format difference comparison and reference integrity. Changes to the diagnostic specification file are automatically reflected in the diagnostic description file. Cross-format synchronization of the two types of files is completed while ensuring that the diagnostic description file can be loaded normally by diagnostic editing tools. This solves the problems of low efficiency and easy omissions in manual comparison and modification in related technologies, and the problem of automatic modification easily destroying reference relationships and causing file unusability.

[0042] Optionally, the diagnostic specification document includes multiple worksheets, each worksheet recording diagnostic data, and the multiple worksheets are associated with each other through a diagnostic object identifier; parsing the diagnostic specification document to obtain the first diagnostic data model includes: Determine the parsing path corresponding to the diagnostic object type; Following the parsing path, extract diagnostic attribute data of the diagnostic object type from the corresponding worksheet, associate the diagnostic attribute data with the diagnostic object identifier, and obtain the structured record corresponding to the diagnostic object type. The structured records are integrated to obtain the first diagnostic data model.

[0043] In one embodiment, the diagnostic specification document is organized in spreadsheet format, containing multiple worksheets, each storing diagnostic data across different dimensions. Data for different diagnostic object types is distributed across different combinations of worksheets, with cross-worksheet relationships established through diagnostic object identifiers. For example, diagnostic attribute data for Data Identifiers (DIDs) is distributed across the DID worksheet and the Input / Output Control worksheet; diagnostic attribute data for Fault Codes (DTCs) is distributed across the DTC worksheet, the Snapshot worksheet, and the Snapshot Data Identifier worksheet; and diagnostic attribute data for Routine Identifiers (RIDs) is distributed across the Control Routine worksheet. The data structures for different diagnostic object types vary significantly, and a uniform parsing method cannot accommodate the diverse data distribution characteristics.

[0044] In one embodiment, the parsing path defines the correspondence between diagnostic object types and worksheets, with different diagnostic object types corresponding to different worksheet combinations and field extraction methods. After determining the parsing path, diagnostic attribute data is extracted from the corresponding worksheets. Using the diagnostic object identifier as the association key, the diagnostic attribute data scattered across different worksheets is aggregated under the same diagnostic object, forming a structured record corresponding to that diagnostic object type. The structured records of each diagnostic object type are integrated to obtain a first diagnostic data model. In the first diagnostic data model, the attribute data of each diagnostic object is organized by type, providing a complete benchmark from the diagnostic specification document for subsequent difference comparisons.

[0045] Specifically, the process of extracting diagnostic attribute data includes merging multi-level headers to normalize column names. If a lower-level header meets a preset invalid identifier condition, the name of the upper-level header is used as the column name; otherwise, the multi-level header names are concatenated into a complete column name. It also includes filtering for null values ​​in the diagnostic attribute data, removing duplicate diagnostic object identifiers, and uniformly converting diagnostic object identifiers to uppercase and removing spaces to eliminate interference from dirty data in the worksheet for subsequent associations and comparisons.

[0046] Because the distribution and header structure of diagnostic data for different diagnostic object types vary across worksheets, a corresponding parsing path is determined for each diagnostic object type. This avoids column name misalignment and data loss caused by reading data in a uniform manner, ensuring that diagnostic attribute data for each diagnostic object type is fully extracted and correctly associated. Association is based on diagnostic object identifiers to aggregate diagnostic attribute data across worksheets into the same diagnostic object, reconstructing the logical relationships between diagnostic objects across worksheets. The integration of structured records enables the first diagnostic data model to cover all diagnostic object types, providing a complete benchmark from the diagnostic specification document for subsequent difference comparisons.

[0047] Optionally, the diagnostic object type includes fault codes; the step of extracting diagnostic attribute data of the diagnostic object type from the corresponding worksheet according to the parsing path, and associating the diagnostic attribute data based on the diagnostic object identifier to obtain the structured record corresponding to the diagnostic object type includes: Extract the attribute data of each fault code from the fault code worksheet; Extract the first correspondence between each fault code and the snapshot group number from the snapshot worksheet; Extract the second correspondence between each snapshot group number and the set of data identifiers from the snapshot data identifier worksheet; Based on the first correspondence and the second correspondence, the data identifier sets of the snapshot group numbers corresponding to each fault code are merged through a set union operation to obtain a list of snapshot data identifiers corresponding to each fault code; Based on the attribute data of each fault code and the snapshot data identifier list, a structured record corresponding to each fault code is obtained.

[0048] In one embodiment, the association between fault codes and snapshot data identifiers is distributed across three worksheets. A fault code can be associated with multiple snapshot groups, and a snapshot group includes multiple data identifiers, resulting in a many-to-many indirect referencing relationship. The fault code worksheet records attribute data for each fault code, including its identifier, description, priority, debouncing parameters, and warning indicator bits. The fault code identifier is represented in six-digit hexadecimal. The snapshot worksheet records the correspondence between fault codes and snapshot group numbers. The snapshot group number is a pre-defined number of digits, extracted through a pre-defined format matching. The snapshot data identifier worksheet records the correspondence between snapshot group numbers and sets of data identifiers. Because the relationship between fault codes and snapshot data identifiers is a many-to-many indirect reference through snapshot groups, the correspondence between fault codes and snapshot data identifiers cannot be directly obtained from a single worksheet. It is necessary to reconstruct the complete mapping from fault codes to snapshot data identifiers by cascading the first and second correspondences.

[0049] Specifically, for example, fault code DTC1 is associated with snapshot groups G1 and G2. G1 contains data identifiers DID_A and DID_B, and G2 contains data identifiers DID_B and DID_C. The snapshot group number set {G1, G2} corresponding to DTC1 is obtained through a first correspondence, and the data identifier set {DID_A, DID_B} corresponding to G1 and the data identifier set {DID_B, DID_C} corresponding to G2 are obtained through a second correspondence. After a set union operation, the snapshot data identifier list for DTC1 is {DID_A, DID_B, DID_C}, where DID_B, as a cross-group duplicate, is automatically removed without a separate deduplication step. Combining the fault code attribute data with the snapshot data identifier list yields a structured record of fault codes, organized by fault code identifier.

[0050] Because the relationship between fault codes and snapshot data identifiers is an indirect many-to-many reference through snapshot groups, it's impossible to directly obtain the correspondence from a single worksheet. By cascading the first and second correspondences, a complete mapping from fault codes to snapshot data identifiers is reconstructed to overcome the break in association caused by scattered records across multiple worksheets. The set union operation is used to merge multiple snapshot groups corresponding to a single fault code and automatically removes duplicate data identifiers across groups, flattening the snapshot data identifier list and eliminating duplicate content. Compared to manual row-by-row comparison across tables, the cascading union method avoids omitting cross-group related data identifiers, ensuring the integrity of the snapshot data identifier list.

[0051] Optionally, the step of parsing the diagnostic description file to obtain the second diagnostic data model includes: Extract the identifier and byte length of the data elements in the diagnostic description file, and establish a first mapping relationship between the identifier and the byte length of the data elements; Extract the data identifier and reference information of the data identifier element in the diagnostic description file, and establish a second mapping relationship between the data identifier and the reference information, wherein the reference information points to the identifier of the data element; Extract the attributes of the diagnostic instances in the diagnostic classification container of the diagnostic description file, and determine the byte length of the diagnostic instance based on the data identifier associated with the diagnostic instance, the second mapping relationship, and the first mapping relationship; The second diagnostic data model is constructed based on the attributes of the diagnostic instance and the byte length.

[0052] In one embodiment, the byte length of a diagnostic instance in the diagnostic description file is indirectly expressed through multiple levels of references from data identifier elements to data elements, and the physical order of the diagnostic instance, data identifier element, and data element in the diagnostic description file is not fixed. A diagnostic instance may appear before the data identifier element and data element it references, and a single scan cannot guarantee that the referenced target has been read during parsing. A phased, progressive strategy is adopted to address this.

[0053] In the first stage, all data elements in the scan diagnostic description file are analyzed, the identification attributes and byte lengths of the data elements are extracted, and the first mapping relationship between the data element identification and the byte length is established.

[0054] In the second stage, all data identifier elements in the scan diagnostic description file are processed, and the data identifiers and reference information of the data identifier elements are extracted. A second mapping relationship is established from the data identifiers to the reference information, and the reference information points to the data element identifiers in the first mapping relationship.

[0055] In the third stage, the diagnostic category containers in the diagnostic description file are traversed to extract the attributes of the diagnostic instances. At this point, the first and second mapping relationships have been established. Based on the data identifier associated with the diagnostic instance, the reference information is obtained through the second mapping relationship, and then the byte length is obtained through the first mapping relationship. The determination of the byte length of the diagnostic instance is not affected by the physical position order of the elements.

[0056] Specifically, the byte length of a data element is determined according to different preset calculation methods based on the data element type. Data element types include field types and atomic types. For field type data elements, the preset maximum length value is used as the byte length. For atomic type data elements, the byte length is determined by dividing the bit length by eight and rounding up. Based on the attributes of the diagnostic instance and the determined byte length, a second diagnostic data model is constructed.

[0057] Because the byte length of a diagnostic instance is indirectly expressed through multiple layers of references, and the order of appearance of the referrer and the referenced is not fixed, a phased mapping is established followed by layer-by-layer querying to avoid the problem of missing reference targets when the referrer appears before the referenced, thus fully determining the byte length of the diagnostic instance. The first and second mapping relationships serve as intermediate lookup tables, allowing the third stage to associate the diagnostic instance with its byte length simply through mapping queries. Compared to a single-scan approach, the phased strategy enables the byte length of the diagnostic instance to be obtained during parsing, providing a second diagnostic data model that includes the byte length dimension.

[0058] Optionally, extracting the attributes of the diagnostic instances in the diagnostic classification container of the diagnostic description file includes: The category name of the diagnostic category container is determined based on the text content of the name element within the diagnostic category container. Static value attributes and name attributes are extracted from the diagnostic classification container, and the service type is determined by text matching. The attributes of the diagnostic instance include the static value attributes, the name attributes, and the service type.

[0059] In one embodiment, the category name of the diagnostic category container is determined by the text content of the name element within the container, rather than by the template reference identifier within the diagnostic description file. The value of the template reference identifier may be regenerated with each version iteration of the diagnostic description file, and identifying the category name based on the template reference identifier is prone to failure during version switching. Determining the category name by the text content of the name element ensures that the identification of the category name does not depend on the internal identifier that changes with version, improving adaptability to different versions of the diagnostic description file.

[0060] Specifically, there is a predefined correspondence between the text content of the name element and the category name. For example, the name text "Dynamic Data" corresponds to the dynamic data category, "IO Control" to the input / output control category, "VariantCoding" to the variant coding category, "Stored Data" to the stored data category, and "ECU Identification" to the electronic control unit identification category. Within the diagnostic category container, diagnostic instances are traversed, static value attributes and name attributes are extracted, and the service type is determined by matching the attribute text with predefined keywords for the service type. For example, matching "ReadDataByIdentifier" corresponds to the data reading service, matching "WriteDataByIdentifier" corresponds to the data writing service, and matching "ReturnControlToECU" corresponds to the input / output control service.

[0061] Because template reference identifiers change with version, text content-based classification names are used to ensure that classification is unaffected by version iterations, thus decoupling the construction of the second diagnostic data model from specific file versions. Service types are determined through text matching, providing attribute basis for comparing service sub-functional dimensions in subsequent difference comparisons. Compared to identification methods based on internal identifiers, text content recognition allows for a consistent benchmark across different versions of diagnostic description files.

[0062] Optionally, before comparing the differences between the diagnostic objects in the first diagnostic data model and the second diagnostic data model, the method further includes: Based on the service sub-function combination of the diagnostic object in the diagnostic specification document, the diagnostic classification of the diagnostic object is inferred according to the preset unified diagnostic service semantic rules, and the diagnostic classification is used as the comparison benchmark for the diagnostic classification dimension in the difference comparison. The difference comparison includes comparing at least one of the following: identifier, name, byte length, service sub-function, session, and security level of the diagnostic object.

[0063] In one embodiment, the diagnostic specification file does not contain an explicit diagnostic category field, while each diagnostic instance in the diagnostic description file belongs to a specific diagnostic category container. The two need to be compared within the same category dimension. To address this, inference rules are designed based on the semantic correspondence between the service sub-functions of the diagnostic object and the diagnostic category, according to the Unified Diagnostic Service (UDS) standard. The Unified Diagnostic Service semantic rules are determined based on the fixed correspondence between service identifiers and diagnostic categories in the UDS standard, and do not rely on template reference identifiers within the diagnostic description file.

[0064] Specifically, the unified diagnostic service semantic rules include multi-level judgments, each executed sequentially according to a preset order, to obtain a unique diagnostic classification when a combination of service sub-functions simultaneously meets multiple conditions. For example, if a combination of service sub-functions includes a return control to ECU service (0x2F), it is inferred to be an input / output control category; if it includes both data read service (0x22) and data write service (0x2E), it is inferred to be a variant configuration category; if it only includes data read service (0x22), it is inferred to be a dynamic data category; if it only includes data write service (0x2E), it is inferred to be a stored data category; and a combination of DIDs (such as ED20 and EDA0) is inferred to be an electronic control unit identifier category. The inferred diagnostic classification is used as the comparison benchmark for the diagnostic classification dimension in the difference comparison, and is compared with the actual classification of the diagnostic instance in the diagnostic description file. If the two are inconsistent, it is marked as a diagnostic classification change.

[0065] In one embodiment, the difference comparison covers multiple attribute dimensions of the diagnostic object, including at least one of identifier existence, name, byte length, service sub-function, session, and security level. The comparison of service sub-functions is accurate to the sub-function level; for example, when the data identifier supports two sub-functions, 2F:00 and 2F:03, they are compared separately. Session and security levels may use different encoding representations in different files; during comparison, they need to be normalized according to preset rules to ensure a unified semantic standard and eliminate spurious differences caused by variations in the expression formats at both ends.

[0066] Since the diagnostic specification document lacks an explicit diagnostic classification field, diagnostic classification is inferred based on the semantic rules of the unified diagnostic service. This compensates for the lack of classification dimensions in the diagnostic specification document, making diagnostic classification an effective dimension for difference comparison. The comparison benchmark is determined based on UDS semantics rather than internal document identifiers, ensuring that diagnostic objects from different versions and sources can be correctly merged into the same category.

[0067] Optionally, modifying the diagnostic instance in the diagnostic description file includes: Select diagnostic instances that meet the preset service coverage conditions from the diagnostic classification container as template diagnostic instances; Clone the template diagnostic instance to generate a new diagnostic instance; The new diagnostic instance is written into the diagnostic classification container to obtain the modified diagnostic description file.

[0068] In one embodiment, modifying the diagnostic description file requires adding a new diagnostic instance to the diagnostic category container. Within the same diagnostic category container, different diagnostic instances contain different numbers of services. A diagnostic instance that meets preset service coverage conditions is selected as a template diagnostic instance, and a template cloning strategy is employed. The reason for choosing the template cloning strategy is that the service nesting structure of a diagnostic instance involves multiple layers of sub-elements such as data object blocks, making direct construction difficult and prone to errors. By using template cloning and filtering, unnecessary services can be removed to adapt to the different service quantity requirements, avoiding the need to add missing service nesting structures out of thin air.

[0069] In one embodiment, the preset service coverage condition is a condition related to the number of services provided by the template diagnostic instance.

[0070] Preferably, the preset service coverage condition is: select the diagnostic instance with the most services in the diagnostic category container as the template diagnostic instance. The reason for selecting this condition is that multi-service templates can adapt to scenarios with fewer service requirements by filtering and deleting unnecessary services, while few-service templates cannot add missing service nesting structures out of thin air, because service nesting structures involve multiple layers of sub-elements such as data object blocks, which are difficult to construct directly and prone to errors.

[0071] Specifically, when cloning a template diagnostic instance, reference attributes and proprietary identifier attributes are distinguished and processed separately using preset attribute recognition rules. Reference attributes include those ending with a preset reference identifier suffix, which retain their original values, allowing the new diagnostic instance to inherit the reference network of the template diagnostic instance. Proprietary identifier attributes include the diagnostic instance's identifier attribute and object identifier attribute, which are replaced with newly generated identifiers, giving the new diagnostic instance an independent identity distinct from the template diagnostic instance. When matching proprietary identifier attributes, reference attributes ending with a preset reference identifier suffix are excluded to avoid mistakenly replacing identifier values ​​in reference attributes. The generated new diagnostic instance is written to the corresponding diagnostic category container, for example, appended to the end of the container, to obtain the modified diagnostic description file.

[0072] Since the service nesting structure of diagnostic instances cannot be added out of thin air, diagnostic instances that meet preset service coverage conditions are selected as templates. This allows for adaptation to different service quantities by reducing rather than adding services, improving the template's adaptability. During cloning, reference attributes and unique identifier attributes are handled separately to maintain the integrity of internal reference relationships within the diagnostic description file while generating new diagnostic instances. This ensures that newly added diagnostic instances naturally satisfy container reference constraints, reducing the risk that modified files cannot be loaded by diagnostic editing tools.

[0073] Optionally, the method further includes performing at least one of the following editing operations based on the difference list: Delete the instance block of the diagnostic instance corresponding to the diagnostic object to be deleted indicated by the difference list; Replace the instance block of the diagnostic instance corresponding to the diagnostic object to be replaced indicated by the difference list with the instance block of the new diagnostic instance; For diagnostic objects with byte length changes indicated by the difference list, replace the data reference of the diagnostic object with a reference to the data object corresponding to the target byte length.

[0074] In one embodiment, different editing operations are performed on the diagnostic description file according to the difference type indicated by the difference list, covering three modification scenarios: addition, deletion, and modification. When a diagnostic object exists in the diagnostic description file but not in the diagnostic specification file, the difference list indicates it needs to be deleted, and a deletion operation is performed, deleting the entire diagnostic instance block corresponding to the diagnostic object. When a diagnostic object exists in the diagnostic specification file but is missing in the diagnostic description file, the difference list indicates it needs to be added, and a replacement operation is performed, replacing the instance block of the corresponding diagnostic instance with the instance block of the cloned new diagnostic instance. During replacement, the reference attribute of the new diagnostic instance is preserved, while its own identifier attribute is replaced. When a diagnostic object exists in both and their byte lengths are inconsistent, the difference list indicates a byte length change, and a data reference modification operation is performed, replacing the data reference of the diagnostic object with a reference to the data object corresponding to the target byte length. The rest of the diagnostic instance remains unchanged.

[0075] Specifically, an instance block is a complete data block corresponding to a diagnostic instance in the diagnostic description file, including all content between the start and end markers of the diagnostic instance. A data object reference is a reference attribute in the diagnostic instance that points to a data element; replacing a data object reference means pointing that reference attribute to a data element with the target byte length.

[0076] Since different difference types in the difference list correspond to different modification requirements, different editing operations are set to cover three modification scenarios: deletion, addition, and attribute changes of diagnostic objects. Operations with the smallest modification granularity are selected according to the difference type to reduce the amount of change in each modification and lower the risk of disrupting reference relationships during the modification process. The delete instance block is used to remove obsolete diagnostic objects from the diagnostic specification file; the instance block that replaces them with new diagnostic instances is used to supplement missing diagnostic objects in the diagnostic description file; and the replace data reference is used to adjust only the byte length while keeping other attributes of the diagnostic instance unchanged, avoiding redundant modifications caused by a complete replacement. All editing operations preserve the reference attributes of the diagnostic instances, ensuring that the reference relationships in the diagnostic description file are not disrupted after editing.

[0077] Optionally, the method further includes: The editing operations performed on the diagnostic description file are sorted in descending order of line number and applied sequentially from the bottom of the diagnostic description file upwards.

[0078] In one embodiment, the diagnostic description file is in text format, and editing operations are located and modified using line numbers. Each editing operation changes the character offset of the diagnostic description file, causing the line numbers of all content below that editing operation to shift. If editing operations are applied sequentially from top to bottom in ascending line number order, the line numbers relied upon by subsequent editing operations will become invalid due to earlier edits, resulting in positioning errors. To address this, all editing operations are sorted in descending line number order and applied sequentially from bottom to top of the diagnostic description file.

[0079] Specifically, for example, for three editing operations located at lines 100, 200, and 300 respectively, after sorting in descending order, the editing operation on line 300 is executed first, then line 200, and finally line 100. When executing from bottom to top, each editing operation only affects the line numbers of the content above it, while the editing operations preceding it are all above it and their line numbers have not yet been modified, thus avoiding positioning errors. The target line number is always the actual line number in the current file during each execution.

[0080] Since each editing operation changes the character offset of the content after its application position, applying the lines in descending order from bottom to top ensures that each editing operation only affects the unprocessed lines above it, while leaving the processed lines below unaffected, thus guaranteeing the positioning accuracy of each editing operation. This determined application order eliminates interference between line numbers in editing operations, allowing multiple editing operations to reliably apply to the correct positions and improving the reliability of modifications.

[0081] Optionally, after obtaining the modified diagnostic description file, the method further includes: The modified diagnostic description file is re-parsed, and the re-parsed diagnostic data is compared again with the diagnostic specification file. After confirming that the difference has been cleared to zero, the modified diagnostic description file is output.

[0082] In one embodiment, after obtaining the modified diagnostic description file, the modified diagnostic description file is re-parsed using the same parsing method as before the modification. The diagnostic data obtained from the re-parsed file is then fully compared with the diagnostic specification file again. If the difference list obtained from the second comparison is empty, meaning the differences have been cleared, it indicates that the modification has brought the two types of files into agreement. At this point, the modified diagnostic description file is output as the final result. If the difference list is not empty, it indicates that there are still unsynchronized contents. Iterative modifications can continue based on the new difference list until the differences are cleared before outputting.

[0083] Because the modified diagnostic description file may contain incomplete synchronization differences, it is re-parsed and compared to verify its consistency with the diagnostic specification file, forming a closed loop of modification and verification. After confirming that the differences are zeroed out, the output is guaranteed to ensure that the output diagnostic description file and the diagnostic specification file are completely consistent at the identification level, meeting the quality traceability requirements of the mass production stage. Compared to delivering after only one modification, the verification closed-loop mechanism makes the modification results traceable, adapting to the quality traceability requirements of the mass production stage.

[0084] This application provides an automatic synchronization device for diagnostic description files, comprising: The first parsing module is used to parse the diagnostic specification document and obtain the first diagnostic data model, which includes diagnostic data organized according to the type of diagnostic object. The second parsing module is used to parse the diagnostic description file to obtain a second diagnostic data model. The second diagnostic data model includes diagnostic instances, and the attributes of the diagnostic instances include reference attributes and proprietary identifier attributes. The comparison module is used to compare the differences between the diagnostic objects in the first diagnostic data model and the second diagnostic data model to obtain a list of differences. The modification module is used to modify the diagnostic instances in the diagnostic description file based on the difference list, retain the reference attribute of the diagnostic instance, replace the own identifier attribute of the diagnostic instance with a new identifier, and obtain the modified diagnostic description file.

[0085] like Figure 2As shown in the embodiment of this application, an electronic device 200 includes a memory 210 and a processor 220; the memory 210 is used to store a computer program; the processor 220 is used to implement the automatic synchronization method of the diagnostic description file as described above when the computer program is executed.

[0086] Alternatively, an electronic device 200 includes a memory 210 and a processor 220 coupled to the memory 210; the memory 210 is configured to store a computer program; and the processor 220 is configured to perform the following operations when the computer program is executed: Parse the diagnostic specification document to obtain a first diagnostic data model, which includes diagnostic data organized by diagnostic object type; Parse the diagnostic description file to obtain a second diagnostic data model. The second diagnostic data model includes diagnostic instances, and the attributes of the diagnostic instances include reference attributes and proprietary identifier attributes. Compare the diagnostic objects in the first diagnostic data model and the second diagnostic data model to obtain a list of differences; Based on the difference list, the diagnostic instances in the diagnostic description file are modified, retaining the reference attribute of the diagnostic instance and replacing the own identifier attribute of the diagnostic instance with a new identifier to obtain the modified diagnostic description file.

[0087] This application provides a computer-readable storage medium storing a computer program. When the computer program is executed by a processor, it implements the automatic synchronization method for diagnostic description files as described above.

[0088] Alternatively, a non-volatile computer-readable storage medium storing a computer program that, when executed by a processor, causes the processor to perform the following operations: Parse the diagnostic specification document to obtain a first diagnostic data model, which includes diagnostic data organized by diagnostic object type; Parse the diagnostic description file to obtain a second diagnostic data model. The second diagnostic data model includes diagnostic instances, and the attributes of the diagnostic instances include reference attributes and proprietary identifier attributes. Compare the diagnostic objects in the first diagnostic data model and the second diagnostic data model to obtain a list of differences; Based on the difference list, the diagnostic instances in the diagnostic description file are modified, retaining the reference attribute of the diagnostic instance and replacing the own identifier attribute of the diagnostic instance with a new identifier to obtain the modified diagnostic description file.

[0089] Electronic device 200, which can serve as a server or client in this application, is described below as an example of hardware devices that can be applied to various aspects of this application. Electronic device 200 is intended to represent various forms of digital electronic computer devices, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. Electronic device 200 can also represent various forms of mobile devices, such as personal digital assistants, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the application described and / or claimed herein.

[0090] Electronic device 200 includes a computing unit that can perform various appropriate actions and processes based on a computer program stored in read-only memory (ROM) or a computer program loaded from a storage unit into random access memory (RAM). The RAM may also store various programs and data required for device operation. The computing unit, ROM, and RAM are interconnected via a bus. Input / output (I / O) interfaces are also connected to the bus.

[0091] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. The storage medium can be a magnetic disk, optical disk, read-only memory (ROM), or random access memory (RAM), etc. In this application, 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 the embodiments of this application according to actual needs. Furthermore, the functional units in the various embodiments of this application 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 units can be implemented in hardware or as software functional units.

[0092] Although the above disclosure is provided, the scope of protection of this application is not limited thereto. Those skilled in the art can make various changes and modifications without departing from the spirit and scope of this application, and all such changes and modifications will fall within the scope of protection of this application.

Claims

1. A method for automatically synchronizing diagnostic description files, characterized in that, include: Parse the diagnostic specification document to obtain a first diagnostic data model, which includes diagnostic data organized by diagnostic object type; Parse the diagnostic description file to obtain a second diagnostic data model. The second diagnostic data model includes diagnostic instances, and the attributes of the diagnostic instances include reference attributes and proprietary identifier attributes. Compare the diagnostic objects in the first diagnostic data model and the second diagnostic data model to obtain a list of differences; Based on the difference list, the diagnostic instances in the diagnostic description file are modified, retaining the reference attribute of the diagnostic instance and replacing the own identifier attribute of the diagnostic instance with a new identifier to obtain the modified diagnostic description file.

2. The automatic synchronization method for diagnostic description files according to claim 1, characterized in that, The diagnostic specification document includes multiple worksheets, each worksheet recording diagnostic data, and the multiple worksheets are linked through diagnostic object identifiers; parsing the diagnostic specification document to obtain the first diagnostic data model includes: Determine the parsing path corresponding to the diagnostic object type; Following the parsing path, extract diagnostic attribute data of the diagnostic object type from the corresponding worksheet, associate the diagnostic attribute data with the diagnostic object identifier, and obtain the structured record corresponding to the diagnostic object type. The structured records are integrated to obtain the first diagnostic data model.

3. The automatic synchronization method for diagnostic description files according to claim 2, characterized in that, The diagnostic object type includes fault codes; the step of extracting diagnostic attribute data of the diagnostic object type from the corresponding worksheet according to the parsing path, and associating the diagnostic attribute data based on the diagnostic object identifier to obtain the structured record corresponding to the diagnostic object type includes: Extract the attribute data of each fault code from the fault code worksheet; Extract the first correspondence between each fault code and the snapshot group number from the snapshot worksheet; Extract the second correspondence between each snapshot group number and the set of data identifiers from the snapshot data identifier worksheet; Based on the first correspondence and the second correspondence, the data identifier sets of the snapshot group numbers corresponding to each fault code are merged through a set union operation to obtain a list of snapshot data identifiers corresponding to each fault code; Based on the attribute data of each fault code and the snapshot data identifier list, a structured record corresponding to each fault code is obtained.

4. The automatic synchronization method for diagnostic description files according to claim 1, characterized in that, The process of parsing the diagnostic description file to obtain the second diagnostic data model includes: Extract the identifier and byte length of the data elements in the diagnostic description file, and establish a first mapping relationship between the identifier and the byte length of the data elements; Extract the data identifier and reference information of the data identifier element in the diagnostic description file, and establish a second mapping relationship between the data identifier and the reference information, wherein the reference information points to the identifier of the data element; Extract the attributes of the diagnostic instances in the diagnostic classification container of the diagnostic description file, and determine the byte length of the diagnostic instance based on the data identifier associated with the diagnostic instance, the second mapping relationship, and the first mapping relationship; The second diagnostic data model is constructed based on the attributes of the diagnostic instance and the byte length.

5. The automatic synchronization method for diagnostic description files according to claim 4, characterized in that, The extraction of attributes from the diagnostic instance in the diagnostic classification container of the diagnostic description file includes: The category name of the diagnostic category container is determined based on the text content of the name element within the diagnostic category container. Static value attributes and name attributes are extracted from the diagnostic classification container, and the service type is determined by text matching. The attributes of the diagnostic instance include the static value attributes, the name attributes, and the service type.

6. The automatic synchronization method for diagnostic description files according to claim 1, characterized in that, Before comparing the differences between the diagnostic objects in the first diagnostic data model and the second diagnostic data model, the method further includes: Based on the service sub-function combination of the diagnostic object in the diagnostic specification document, the diagnostic classification of the diagnostic object is inferred according to the preset unified diagnostic service semantic rules, and the diagnostic classification is used as the comparison benchmark for the diagnostic classification dimension in the difference comparison. The difference comparison includes comparing at least one of the following: identifier, name, byte length, service sub-function, session, and security level of the diagnostic object.

7. The automatic synchronization method for diagnostic description files according to claim 1, characterized in that, The modification of the diagnostic instance in the diagnostic description file includes: Select diagnostic instances that meet the preset service coverage conditions from the diagnostic classification container as template diagnostic instances; Clone the template diagnostic instance to generate a new diagnostic instance; The new diagnostic instance is written into the diagnostic classification container to obtain the modified diagnostic description file.

8. The automatic synchronization method for diagnostic description files according to claim 7, characterized in that, The method further includes performing at least one of the following editing operations based on the difference list: Delete the instance block of the diagnostic instance corresponding to the diagnostic object to be deleted indicated by the difference list; Replace the instance block of the diagnostic instance corresponding to the diagnostic object to be replaced indicated by the difference list with the instance block of the new diagnostic instance; For diagnostic objects with byte length changes indicated by the difference list, replace the data reference of the diagnostic object with a reference to the data object corresponding to the target byte length.

9. The automatic synchronization method for diagnostic description files according to claim 8, characterized in that, The method further includes: The editing operations performed on the diagnostic description file are sorted in descending order of line number and applied sequentially from the bottom of the diagnostic description file upwards.

10. The automatic synchronization method for diagnostic description files according to claim 1, characterized in that, After obtaining the modified diagnostic description file, the process also includes: The modified diagnostic description file is re-parsed, and the re-parsed diagnostic data is compared again with the diagnostic specification file. After confirming that the difference has been cleared to zero, the modified diagnostic description file is output.

11. An automatic synchronization device for diagnostic description files, characterized in that, include: The first parsing module is used to parse the diagnostic specification document and obtain the first diagnostic data model, which includes diagnostic data organized according to the type of diagnostic object. The second parsing module is used to parse the diagnostic description file to obtain a second diagnostic data model. The second diagnostic data model includes diagnostic instances, and the attributes of the diagnostic instances include reference attributes and proprietary identifier attributes. The comparison module is used to compare the differences between the diagnostic objects in the first diagnostic data model and the second diagnostic data model to obtain a list of differences. The modification module is used to modify the diagnostic instances in the diagnostic description file based on the difference list, retain the reference attribute of the diagnostic instance, replace the own identifier attribute of the diagnostic instance with a new identifier, and obtain the modified diagnostic description file.

12. An electronic device, characterized in that, Including memory and processor; The memory is used to store computer programs; The processor is configured to, when executing the computer program, implement the automatic synchronization method for diagnostic description files as described in any one of claims 1-10.

13. A computer-readable storage medium, characterized in that, The storage medium stores a computer program that, when executed by a processor, implements the automatic synchronization method for diagnostic description files as described in any one of claims 1-10.

Images