Method and apparatus for automatic modification of a vehicle diagnostic description file

Abstract

The application provides an automatic modification method and device of a vehicle diagnosis description file, and relates to the technical field of vehicle diagnosis. The method comprises the following steps: obtaining a target diagnosis object and a vehicle diagnosis description file; determining a target diagnosis classification container to which the target diagnosis object belongs according to a service sub-function combination of the target diagnosis object in a diagnosis demand file; selecting a template diagnosis instance in the target diagnosis classification container, cloning the template diagnosis instance, and generating a new diagnosis instance corresponding to the target diagnosis object; and writing the new diagnosis instance into the target diagnosis classification container to obtain a modified vehicle diagnosis description file, so that the reference relationship between internal objects of the file is not damaged when the vehicle diagnosis description file is modified.

Description

Technical Field

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

[0002] A vehicle diagnostic description file is a standardized data file used to define the diagnostic communication interface of an electronic control unit (ECU). Diagnostic tools load the vehicle diagnostic description file to enable diagnostic service interaction with various ECUs in the vehicle, such as data reading, fault code reading, and input / output control. The vehicle diagnostic description file is stored in Extensible Markup Language (XML) format and contains a multi-level nested element structure. Elements reference each other through identifiers, forming complex referencing relationships.

[0003] In related technologies, when diagnostic requirements change, updating the vehicle diagnostic description file primarily employs two methods. One method involves engineers manually modifying the text within the vehicle diagnostic description file, adding or modifying diagnostic instances. The other method is to completely regenerate the vehicle diagnostic description file based on the updated diagnostic requirements file, overwriting the original file.

[0004] Manual modification is inefficient and prone to missing synchronous updates of reference relationships when dealing with a large number of diagnostic instances, leading to inconsistencies in the internal reference relationships of the modified vehicle diagnostic description file. While full regeneration can ensure consistency of reference relationships, it overwrites manually verified configuration content already present in the vehicle diagnostic description file, resulting in the loss of existing configurations. Automatic incremental modification of the vehicle diagnostic description file can easily disrupt internal reference relationships, preventing the modified file from being correctly loaded by diagnostic tools. Summary of the Invention

[0005] The problem addressed in this application is how to modify a vehicle diagnostic description file without disrupting the reference relationships between objects within the file.

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

[0007] Firstly, this application provides a method for automatically modifying a vehicle diagnostic description file, including: Obtain the target diagnostic object and the vehicle diagnostic description file, wherein the vehicle diagnostic description file includes a diagnostic classification container, and the diagnostic classification container includes diagnostic instances; Based on the combination of service sub-functions of the target diagnostic object in the diagnostic requirements file, determine the target diagnostic category container to which the target diagnostic object belongs; A template diagnostic instance is selected in the target diagnostic classification container, the template diagnostic instance is cloned, and a new diagnostic instance corresponding to the target diagnostic object is generated. The template diagnostic instance has attributes including a reference attribute and a unique identifier attribute. The value of the reference attribute points to other objects in the vehicle diagnostic description file, and the value of the unique identifier attribute is the identifier of the diagnostic instance itself. When cloning, the value of the reference attribute remains unchanged, and the value of the unique identifier attribute is replaced with the new identifier. The new diagnostic instance is written into the target diagnostic classification container to obtain the modified vehicle diagnostic description file.

[0008] Optionally, obtaining the target diagnostic object includes: Obtain a difference list, which records the attribute differences of the diagnostic object between the diagnostic requirement file and the vehicle diagnostic description file; The target diagnostic object is determined from the list of differences.

[0009] Optionally, determining the target diagnostic category container to which the target diagnostic object belongs based on the combination of service sub-functions in the diagnostic requirements file includes: When the target diagnostic object is a combined data identifier that aggregates multiple sub-data identifiers, the target diagnostic classification container is determined to be an identification information container; When the service sub-function combination includes an input / output control service, the target diagnostic classification container is determined to be an input / output control container; When the service sub-function combination includes both data reading service and data writing service, the target diagnostic classification container is determined to be a variant configuration container. When the service sub-function combination only includes the data reading service, the target diagnostic classification container is determined to be a dynamic data container; When the service sub-function combination only includes the data writing service, the target diagnostic classification container is determined to be a data storage container.

[0010] Optionally, replacing the value of the proprietary identifier attribute with the new identifier includes: The attribute names of the template diagnostic instance are matched using a negative lookback regular expression, wherein attribute names ending with a reference identifier are excluded by the negative lookback regular expression. The attribute corresponding to the attribute name that was not excluded is determined as the proprietary identifier attribute, and the assignment position of the proprietary identifier attribute is located in the text of the template diagnostic instance. Replace the value at the assignment position with the new identifier.

[0011] Optionally, the method further includes performing at least one of the following editing operations on the vehicle diagnostic description file 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.

[0012] Optionally, the method further includes: In the new diagnostic instance, delete the unsupported services indicated by the difference list and the corresponding data object blocks of the unsupported services. After each deletion, rescan the text of the vehicle diagnostic description file to obtain the updated matching position; make subsequent modifications based on the updated matching position.

[0013] Optionally, the method further includes: sorting the editing operations performed on the vehicle diagnostic description file in descending order of line number; and applying the editing operations sequentially from the bottom to the top of the vehicle diagnostic description file.

[0014] Optionally, when the target diagnostic object is a fault code, the method further includes: The fault code record corresponding to the fault code is simultaneously written into each fault code record container in the vehicle diagnostic description file, wherein each fault code record container does not include the on-board diagnostic fault code container; the fault code record in each fault code record container has an independent identifier.

[0015] Optionally, after obtaining the modified vehicle diagnostic description file, the method further includes: The modified vehicle diagnostic description file is re-parsed, and the diagnostic data obtained from the re-parsed file is compared with the diagnostic requirement file again. After confirming that the differences at the diagnostic object identifier level are cleared to zero, the modified vehicle diagnostic description file is output.

[0016] Secondly, this application provides an automatic modification device for vehicle diagnostic description files, comprising: The acquisition module is used to acquire the target diagnostic object and the vehicle diagnostic description file, wherein the vehicle diagnostic description file includes a diagnostic classification container, and the diagnostic classification container includes diagnostic instances; The determination module is used to determine the target diagnostic category container to which the target diagnostic object belongs based on the combination of service sub-functions of the target diagnostic object in the diagnostic requirements file; The cloning module is used to select a template diagnostic instance in the target diagnostic classification container, clone the template diagnostic instance, and generate a new diagnostic instance corresponding to the target diagnostic object. The template diagnostic instance has attributes including a reference attribute and a unique identifier attribute. The value of the reference attribute points to other objects in the vehicle diagnostic description file, and the value of the unique identifier attribute is the identifier of the diagnostic instance itself. During cloning, the value of the reference attribute remains unchanged, and the value of the unique identifier attribute is replaced with a new identifier. The writing module is used to write the new diagnostic instance into the target diagnostic classification container to obtain the modified vehicle diagnostic description file.

[0017] The beneficial effects of the automatic modification method for vehicle diagnostic description files in this application are: This incremental modification scheme maintains referential integrity by locating the object to be modified, determining the target diagnostic classification container based on the combination of service sub-functions, cloning a template diagnostic instance to generate a new diagnostic instance, differentiating attributes into reference attributes and unique identifier attributes and processing them differently, and writing them into the target diagnostic classification container. During incremental modification, by keeping the values ​​of reference attributes unchanged while only replacing the values ​​of unique identifier attributes, the reference relationships are guaranteed not to be broken at the attribute level. This ensures that the internal reference relationships of the modified vehicle diagnostic description file remain consistent and can be correctly loaded by diagnostic tools, thus solving the problem of easily broken reference relationships when incrementally modifying vehicle diagnostic description files. Attached Figure Description

[0018] Figure 1 This is a flowchart illustrating the automatic modification method for vehicle 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

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

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

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

[0022] 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".

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

[0024] like Figure 1 As shown in the embodiment of this application, an automatic modification method for a vehicle diagnostic description file is provided, including: Step S100: Obtain the target diagnostic object and the vehicle diagnostic description file, wherein the vehicle diagnostic description file includes a diagnostic classification container, and the diagnostic classification container includes diagnostic instances.

[0025] In one embodiment, the target diagnostic object represents a diagnostic configuration unit to be modified, such as a data identifier, fault code, routine identifier, etc. The target diagnostic object can be obtained in various ways, such as by comparing a diagnostic requirement document with a vehicle diagnostic description document to generate a difference list, and identifying diagnostic objects with attribute differences from the difference list as target diagnostic objects; or by receiving a diagnostic object specified by external input as the target diagnostic object.

[0026] Diagnostic requirements documents (DQAs) are diagnostic requirements specifications written and maintained by OEMs. They define the diagnostic configurations that vehicle electronic control units (ECUs) should support, such as system service description documents in spreadsheet format. The target diagnostic objects are recorded in the DQAs with corresponding combinations of service sub-functions.

[0027] A vehicle diagnostic description file (DMR) represents the diagnostic description file used in the engineering implementation. It is compiled, flashed into the electronic control unit (ECU), and read by diagnostic instruments during production line terminal testing. Examples include DMRs based on Extensible Markup Language (EXPLAIN). The vehicle DMR uses a multi-layered nested container structure. Diagnostic instances are categorized into different diagnostic category containers according to their functions, and each diagnostic instance is interconnected with other objects in the vehicle DMR through reference relationships.

[0028] Step S200: Determine the target diagnostic category container to which the target diagnostic object belongs based on the combination of service sub-functions of the target diagnostic object in the diagnostic requirements file.

[0029] In one embodiment, a service sub-function combination is a collection of one or more diagnostic services supported by the target diagnostic object in the diagnostic requirements file. The diagnostic requirements file does not have a explicitly defined diagnostic classification field; however, when writing a diagnostic instance to the vehicle diagnostic description file, it is necessary to first determine the diagnostic classification container to which the diagnostic instance belongs. Diagnostic service standards define fixed semantics for each diagnostic service. Diagnostic classification containers organize diagnostic instances according to functional classifications. A correspondence exists between service sub-function combinations and diagnostic classification containers based on the semantics of the diagnostic service standards. Therefore, the target diagnostic classification container to which the target diagnostic object belongs can be determined based on the service sub-function combinations.

[0030] Since the correspondence originates from the semantics of the diagnostic service standard, the determination of the target diagnostic classification container is not affected by the version iteration of the vehicle diagnostic description file and is applicable to different versions of the vehicle diagnostic description file. The determined target diagnostic classification container provides the range of template diagnostic instances for step S300 and the writing location of new diagnostic instances for step S400, enabling the modification content to be accurately located in the vehicle diagnostic description file.

[0031] Step S300: Select a template diagnostic instance from the target diagnostic classification container, clone the template diagnostic instance, and generate a new diagnostic instance corresponding to the target diagnostic object. The template diagnostic instance has attributes including a reference attribute and a unique identifier attribute. The value of the reference attribute points to other objects in the vehicle diagnostic description file, and the value of the unique identifier attribute is the identifier of the diagnostic instance itself. During cloning, the value of the reference attribute remains unchanged, and the value of the unique identifier attribute is replaced with the new identifier.

[0032] In one embodiment, the template diagnostic instance is a diagnostic instance selected from the target diagnostic classification container as the cloning source. The diagnostic instance has a multi-level nested structure in the vehicle diagnostic description file, containing sub-elements such as services and data objects. Building such a nested structure from scratch is complex and error-prone. By using an existing diagnostic instance in the target diagnostic classification container as a template for cloning, the generated new diagnostic instance can directly inherit the complete structure consistent with the existing structure of the vehicle diagnostic description file.

[0033] The attributes of template diagnostic instances are divided into two categories based on their function. Reference attributes point to other objects in the vehicle diagnostic description file. Each diagnostic instance forms a reference network across different levels and containers through these attributes. During cloning, the values ​​of reference attributes remain unchanged. The new diagnostic instance inherits the reference relationships between the template diagnostic instance and other objects, and the reference network is not broken during cloning. However, if the values ​​of reference attributes are changed during the cloning process, the reference network will be destroyed, and the modified vehicle diagnostic description file will not be loaded by the diagnostic tool. The unique identifier attribute is the diagnostic instance's own identifier. If the original value is retained after cloning, the new diagnostic instance and the template diagnostic instance will have the same identifier, causing an identifier conflict, and the vehicle diagnostic description file will also be unusable. Therefore, the value of the unique identifier attribute is replaced with a new identifier, giving the new diagnostic instance a unique identifier that distinguishes it from other diagnostic instances.

[0034] Specifically, the new identifier is generated by concatenating the container type identifier of the target diagnostic category container and the object identifier of the target diagnostic object in the diagnostic requirements file. The container type identifier identifies the diagnostic category container type to which the new diagnostic instance belongs, and the object identifier identifies the target diagnostic object itself. Through this generation rule, the new identifier reflects both the classification of the new diagnostic instance and corresponds one-to-one with the target diagnostic object, ensuring the uniqueness of the new identifier in the vehicle diagnostic description file. Furthermore, the generation of the new identifier does not depend on the identifier of the template diagnostic instance, avoiding the generation of duplicate identifiers when different target diagnostic objects clone the same template.

[0035] For example, if the target diagnostic classification container is a dynamic data container with a container type identifier of "DID", and the object identifier of the target diagnostic object in the diagnostic requirement file is "F010", then the generated new identifier will be "id_DID_F010". The original identifier of the template diagnostic instance is "id_DID_0042". During cloning, the value of the self-identifying attribute "id" is replaced from "id_DID_0042" to "id_DID_F010", while the values ​​of reference attributes such as "dtref" and "idref" remain unchanged. When there are multiple target diagnostic objects in the target diagnostic classification container, each target diagnostic object has a different object identifier, resulting in different generated new identifiers and no identifier conflicts.

[0036] In another embodiment, the rule for generating the new identifier can be replaced by concatenating the container type identifier of the target diagnostic classification container, the object identifier of the target diagnostic object, and the version identifier to generate the new identifier. The version identifier is used to distinguish diagnostic instances generated from different modifications, and is suitable for scenarios where multiple new diagnostic instances are generated from the same target diagnostic object in multiple modifications. For example, the new identifier is "id_DID_F010_v2", where "v2" represents the version generated in the second modification. This generation rule avoids identifier conflicts between new diagnostic instances generated from different modifications when the vehicle diagnostic description file undergoes multiple incremental modifications.

[0037] Step S400: Write the new diagnostic instance into the target diagnostic classification container to obtain the modified vehicle diagnostic description file.

[0038] In one embodiment, the new diagnostic instance is written into the target diagnostic classification container determined in step S200, that is, into the diagnostic classification container that matches the service sub-function combination. The classification organization of the modified vehicle diagnostic description file is consistent with the diagnostic requirement file. The differences between the obtained modified vehicle diagnostic description file and the diagnostic requirement file in terms of content are eliminated, and the integrity of the reference relationships in terms of structure is maintained. It is used for compilation and flashing into the electronic control unit for use in production line terminal diagnostic testing.

[0039] In this embodiment, the automatic modification method for vehicle diagnostic description files starts from a difference list. For a target diagnostic object, it first determines the target diagnostic category container to which the target diagnostic object belongs based on the service sub-function combination. Then, within the target diagnostic category container, using a template diagnostic instance as a blueprint, it clones the object by distinguishing between reference attributes and proprietary identifier attributes, keeping the values ​​of reference attributes unchanged and replacing the values ​​of proprietary identifier attributes. Finally, the generated new diagnostic instance is written into the target diagnostic category container. Overall, this constitutes a difference-driven automatic modification that maintains integrity. When automatically modifying the vehicle diagnostic description file, it accurately locates the position of the modified content within the vehicle diagnostic description file, without disrupting the internal reference relationships of the file. This ensures that the modified vehicle diagnostic description file can be loaded and used normally by diagnostic tools, while retaining the existing configuration content in the vehicle diagnostic description file, adapting to the rapid pace of changes in diagnostic requirements during mass production.

[0040] Optionally, obtaining the target diagnostic object includes: Obtain a difference list, which records the attribute differences of the diagnostic object between the diagnostic requirement file and the vehicle diagnostic description file; The target diagnostic object is determined from the list of differences.

[0041] In one embodiment, the difference list represents the result generated by comparing attributes after parsing the diagnostic requirements file and the vehicle diagnostic description file respectively. Each item in the difference list records the attribute differences of a diagnostic object between the diagnostic requirements file and the vehicle diagnostic description file. Attribute differences include two types: one is existence difference, that is, the diagnostic object exists in the diagnostic requirements file but does not exist in the vehicle diagnostic description file, or the diagnostic object exists in the vehicle diagnostic description file but does not exist in the diagnostic requirements file; the other is attribute value difference, that is, the diagnostic object exists in both but at least one attribute value is different.

[0042] The target diagnostic object is determined from the difference list. Each item in the difference list corresponds to a diagnostic object with a difference; this is the target diagnostic object.

[0043] Modifications are driven by a difference list, limiting the scope of changes to diagnostic objects that exhibit differences. This differs from regenerating the entire diagnostic description file, ensuring that existing configuration content, such as manually verified configurations, is preserved. Furthermore, the difference list automatically identifies objects requiring modification, avoiding the risk of omissions during manual item-by-item checks.

[0044] Specifically, the difference list covers attribute differences for three types of diagnostic objects: data identifiers, fault codes, and routine identifiers. For data identifiers, comparison dimensions include attributes such as service list, byte length, and data format; for fault codes, comparison dimensions include attributes such as snapshot identifier association and fault code parameters; and for routine identifiers, comparison dimensions include attributes such as service list, request parameters, and response parameters. For example, if a data identifier supports both 0x22 and 0x2E services in the diagnostic requirements file, but only supports 0x22 services in the vehicle diagnostic description file, then this data identifier has a difference in its service list attribute value and is recorded in the difference list, becoming a target diagnostic object in the subsequent modification process.

[0045] Optionally, determining the target diagnostic category container to which the target diagnostic object belongs based on the combination of service sub-functions in the diagnostic requirements file includes: When the target diagnostic object is a combined data identifier that aggregates multiple sub-data identifiers, the target diagnostic classification container is determined to be an identification information container; When the service sub-function combination includes an input / output control service, the target diagnostic classification container is determined to be an input / output control container; When the service sub-function combination includes both data reading service and data writing service, the target diagnostic classification container is determined to be a variant configuration container. When the service sub-function combination only includes the data reading service, the target diagnostic classification container is determined to be a dynamic data container; When the service sub-function combination only includes the data writing service, the target diagnostic classification container is determined to be a data storage container.

[0046] In one embodiment, the diagnostic requirement file does not contain a diagnostic category field; the diagnostic category container to which the diagnostic object belongs needs to be inferred from the service sub-function combination. The service sub-function combination represents the set of diagnostic services and sub-functions supported by the diagnostic object in the diagnostic requirement file. A unified diagnostic service standard defines fixed semantics for each diagnostic service, and a fixed correspondence exists between service sub-function combinations and diagnostic category containers based on this standard semantics. The judgment logic is executed sequentially in the order of combined data identifier, input / output control service, data reading service, and data writing service. When the judgment at the beginning is successful, the corresponding diagnostic category container is determined, and subsequent judgments are not executed. The reason for this order is that the combined data identifier carries the identification information of each sub-data identifier, and regardless of its service sub-function combination, it is classified into the identification information container and needs to be identified first; the input / output control service is specifically used for actuator control in the unified diagnostic service standard, and its classification takes precedence over the judgment of read / write capabilities.

[0047] Specifically, a combined data identifier aggregates multiple sub-data identifiers, such as identifiers ED20 and EDA0. This type of diagnostic object is identified as an identification information container, corresponding to the "ECUIdentification" diagnostic category in the vehicle diagnostic description file. When a service sub-function combination includes an input / output control service (i.e., a service with service identifier 0x2F), it is identified as an input / output control container, corresponding to the "IOControl" diagnostic category in the vehicle diagnostic description file. When a service sub-function combination includes both a data read service (i.e., a service with service identifier 0x22) and a data write service (i.e., a service with service identifier 0x2E), it indicates that the diagnostic object has both read and write capabilities and is used for variant configuration; therefore, it is identified as a variant configuration container, corresponding to the "VariantCoding" diagnostic category in the vehicle diagnostic description file. When a service sub-function combination only includes a data read service, it is identified as a dynamic data container, corresponding to the "Dynamic Data" diagnostic category in the vehicle diagnostic description file. When a service sub-function combination only includes a data write service, it is identified as a stored data container, corresponding to the "StoredData" diagnostic category in the vehicle diagnostic description file.

[0048] In one embodiment, the identification of each service in the service sub-function combination is achieved by semantic matching of service names. In another embodiment, semantic matching of service names can be replaced by numerical matching of unified diagnostic service identifiers, such as directly matching values ​​like 0x22, 0x2E, and 0x2F. The two methods are functionally equivalent, differing only in the matching keys.

[0049] The inference rule is based on the semantic definition of the unified diagnostic service standard and does not rely on the internal identifiers of the vehicle diagnostic description file. In related technologies, diagnostic categories are identified by the globally unique identifier tmplref within the vehicle diagnostic description file. Different versions of the vehicle diagnostic description file use different globally unique tmplref identifiers for the same diagnostic category, and the identification completely fails when the internal identifier is regenerated due to version iteration. The inference rule of this embodiment has been verified on two vehicle diagnostic description file versions, 25R2 and 26R1, with an inference accuracy of 100%. The inferred diagnostic category is also used to compare with the actual diagnostic category of the diagnostic object in the vehicle diagnostic description file. When the two are inconsistent, it is marked as a diagnostic category change and included as an attribute difference in the difference list.

[0050] Diagnostic requirements documents are spreadsheet files, such as Excel, CSV, and ODS formats. The diagnostic classification container has a functionally equivalent structure in the ODX format, i.e., the ISO 22901 standard format diagnostic description file. The ODX-DIAG-LAYER container structure is functionally equivalent to the diagnostic classification container in the vehicle diagnostic description file, and the above inference rules also apply to ODX format diagnostic description files.

[0051] Optionally, replacing the value of the proprietary identifier attribute with the new identifier includes: The attribute names of the template diagnostic instance are matched using a negative lookback regular expression, wherein attribute names ending with a reference identifier are excluded by the negative lookback regular expression. The attribute corresponding to the attribute name that was not excluded is determined as the proprietary identifier attribute, and the assignment position of the proprietary identifier attribute is located in the text of the template diagnostic instance. Replace the value at the assignment position with the new identifier.

[0052] In an embodiment, in the Extensible Markup Language text of the vehicle diagnostic description file, the text forms of the reference attribute and the own identification attribute are similar, both adopting the format of "attribute name='value'". The reference attributes include shstaticref, shproxyref, tmplref, idref, dtref, etc., and the own identification attributes include id and oid. If a simple string replacement is used to replace the identification value in the template diagnostic instance text with a new identifier, the identification values in the reference attributes will be replaced together, resulting in broken reference relationships and the modified vehicle diagnostic description file cannot be loaded by the diagnostic tool.

[0053] Specifically, when the negative lookbehind regular expression matches the id attribute and the oid attribute, it automatically excludes all attribute prefixes ending with ref, such as didRef, shstaticref, shproxyref, idref, tmplref, dtref, attrref, etc., without the need to write separate exclusion rules for each reference attribute. At the same time, the id attribute and the oid attribute are distinguished by leading spaces, that is, the text pattern of " id='...'" is matched to avoid erroneous extraction caused by the id substring contained in the attribute name of the oid attribute. For example, the negative lookbehind regular expression is: (?<!ref)"\s*(?:id|oid)\s*".

[0054] The lookbehind part "(?<!ref)" of the negative lookbehind regular expression is used to exclude cases where the attribute name ends with "ref", so that the regular expression only matches the "id" or "oid" attribute names that do not end with "ref". Through the above matching method, the values of the reference attributes remain the original values during the cloning process, and the reference relationships between the new diagnostic instance and other objects in the vehicle diagnostic description file are completely preserved.

[0055] Optionally, the method further comprises: performing at least one of the following editing operations on the vehicle diagnostic description file according to the difference list: deleting the instance block of the diagnostic instance corresponding to the to-be-deleted diagnostic object indicated by the difference list; replacing the instance block of the diagnostic instance corresponding to the to-be-replaced diagnostic object indicated by the difference list with the instance block of the new diagnostic instance; for the diagnostic object with a changed byte length indicated by the difference list, replacing the data reference of the diagnostic object with the reference of the data object corresponding to the target byte length.

[0056] In one embodiment, the above-described deletion, replacement, and modification operations are combined with the addition operation of writing the new diagnostic instance into the target diagnostic category container, covering all modification scenarios indicated by the difference list. The smallest granularity editing operation is selected according to the difference type: a deletion operation is performed when the diagnostic object does not exist in the diagnostic requirement file but exists in the vehicle diagnostic description file; a modification operation is performed when the diagnostic object exists in both and only the byte length differs; a replacement operation is performed when the diagnostic object exists in both and multiple attribute differences exist; and an addition operation is performed when the diagnostic object exists in the diagnostic requirement file but not in the vehicle diagnostic description file. Selecting the smallest granularity operation according to the difference type reduces the amount of change in each modification and lowers the risk of damaging reference relationships during the modification process.

[0057] Specifically, the `add` operation inserts the new diagnostic instance at the end of the target diagnostic category container. The `delete` operation deletes the entire diagnostic instance block corresponding to the diagnostic object to be deleted. The `replace` operation completely replaces the old instance block with the instance block of the cloned new diagnostic instance, maintaining the continuity of references between diagnostic instances, such as the continuity of `didRef` references. The `modify` operation only replaces the data references of the diagnostic object with references to data objects of the target byte length; for example, replacing the `dtref` attribute of a `DATAOBJ` or `STRUCT` element with a reference to an `IDENT` element of the correct byte length, leaving the rest of the diagnostic instance unchanged.

[0058] Optionally, the method further includes: In the new diagnostic instance, delete the unsupported services indicated by the difference list and the corresponding data object blocks of the unsupported services. After each deletion, rescan the text of the vehicle diagnostic description file to obtain the updated matching position; make subsequent modifications based on the updated matching position.

[0059] In one embodiment, the template diagnostic instance is selected as the diagnostic instance with the most services in the target diagnostic category container. The reason for selecting the diagnostic instance with the most services as the template is that a template with multiple services can adapt to the needs of fewer services by filtering out unnecessary services, while a template with fewer services cannot add missing service nesting structures out of thin air. Service nesting structures involve sub-elements such as SIMPLECOMPCONT and SPECDATAOBJ. When extracting the template diagnostic instance, shproxyref mappings are collected synchronously as subsequent location anchors to avoid hardcoding globally unique identifiers. Since the template diagnostic instance is the diagnostic instance with the most services, the newly cloned diagnostic instance may contain services not supported by the diagnostic requirements file. Therefore, unsupported services indicated by the difference list and the corresponding data object blocks, such as the SPECDATAOBJ block, are deleted to ensure that the service configuration of the new diagnostic instance is consistent with the diagnostic requirements file.

[0060] Specifically, when deleting service and data object blocks, each deletion changes the character offset of the subsequent content within the text, and the pre-cached regular expression matching positions become invalid after the first modification. To address this, the vehicle diagnostic description file text is rescanned after each deletion to obtain the updated matching positions. Subsequent modifications are then based on these updated positions, ensuring accurate positioning of subsequent changes. For example, with approximately 600 deletion operations performed in a single run, the rescanning mechanism ensures zero positioning accuracy for each deletion operation.

[0061] In another embodiment, the selection of the template diagnostic instance can be replaced by selecting the first diagnostic instance in the target diagnostic classification container, or selecting a specifically named diagnostic instance in the target diagnostic classification container. The former is simpler to implement, while the latter is more controllable.

[0062] Optionally, it also includes: sorting the editing operations performed on the vehicle diagnostic description file in descending order of line number; and applying the editing operations sequentially from the bottom up of the vehicle diagnostic description file.

[0063] In one embodiment, the position of each diagnostic instance in the vehicle diagnostic description file is marked by line numbers. When parsing the vehicle diagnostic description file, the start and end line numbers of each diagnostic instance are recorded as modification positioning anchor points. If editing operations are applied from top to bottom, the first applied editing operation will change the line numbers of subsequent content, causing the positioning of subsequent editing operations to fail. The editing operations are sorted in descending order of line numbers and applied sequentially from the bottom to the top of the vehicle diagnostic description file. When any editing operation is applied, the line numbers of the content above that editing operation have not yet been modified, and the positioning anchor points of each editing operation always remain valid.

[0064] Specifically, the editing operations are sorted by target line number from largest to smallest. The operation with the largest line number is applied first, followed by the operation with the second largest line number, and so on. For example, if the target line numbers for three editing operations are line 500, line 300, and line 100, after sorting in descending order, the operation for line 500 is applied first. This operation affects line numbers 500 and above, but not line numbers 300 and 100. Then the operation for line 300 is applied, and finally the operation for line 100 is applied. In a real-world project, approximately 600 editing operations were executed in a single run without any positioning errors.

[0065] In another embodiment, the edit location can be replaced by content hashing, which involves calculating a hash value (e.g., SHA256 hash) for the instance blocks of the diagnostic instance and then locating the edit location using that hash value. Content hashing is more robust in scenarios where the vehicle diagnostic description file has been modified by other tools, but its computational cost is higher than line numbering.

[0066] Optionally, when the target diagnostic object is a fault code, the method further includes: The fault code record corresponding to the fault code is simultaneously written into each fault code record container in the vehicle diagnostic description file, wherein each fault code record container does not include the on-board diagnostic fault code container; the fault code record in each fault code record container has an independent identifier.

[0067] In one embodiment, fault code records exist simultaneously in multiple fault code record containers within the vehicle diagnostic description file. For example, the `faultMemory` container stores fault codes, the `obdFaultMemory` container (the on-board diagnostic fault code container) stores on-board diagnostic fault codes, and other fault code record containers store snapshot associations and auxiliary information. Fault code records for the same fault code in different fault code record containers have different identifiers. When a new fault code is added, if the fault code record is only written to some of the fault code record containers, functions such as fault code snapshot association will be lost. Therefore, fault code records are simultaneously written to all fault code record containers except the on-board diagnostic fault code container, and each fault code record in each container has an independent identifier. The type of each fault code record container can be automatically identified through the `rtSpec` attribute and fault code record count of the fault code record container, avoiding the failure of snapshot data identifier association due to extracting identifiers from incorrect fault code record containers.

[0068] Specifically, when writing fault code records, the parameter elements of the fault code, such as the UNSRECORDITEM element, have no explicit semantic labels. If the meaning of the parameters is identified through internal identifiers, parameter identification will fail when the internal identifiers are regenerated due to vehicle diagnostic description file version upgrades. Therefore, the meaning of the parameters is determined according to their order of appearance in the fault code record. For example, the first parameter is identified as the aging threshold (agedDTCLimit), the second as the priority, the third as the step_up debouncing parameter, and the fourth as the step_down debouncing parameter, making the writing of fault code parameters independent of internal identifiers, applicable to different versions of vehicle diagnostic description files. For example, if the target diagnostic object is fault code "P0100", the corresponding fault code record is written to both the faultMemory container and the snapshot association container. The identifier of the fault code record in the faultMemory container is "id_DTC_P0100_FM", and the identifier of the fault code record in the snapshot association container is "id_DTC_P0100_SN". The two identifiers are independent of each other.

[0069] Because the editing of fault codes involves synchronous writing to multiple fault code recording containers, an ascending-order strategy with offset accumulation is adopted. That is, after writing is completed in each fault code recording container, the row number offset generated by the writing is accumulated into the positioning row number of the subsequent fault code recording container. This, together with the strategy of applying the strategy in descending order of row number mentioned above, ensures accurate positioning of the writing of multiple fault code recording containers.

[0070] Optionally, after obtaining the modified vehicle diagnostic description file, the method further includes: The modified vehicle diagnostic description file is re-parsed, and the diagnostic data obtained from the re-parsed file is compared with the diagnostic requirement file again. After confirming that the differences at the diagnostic object identifier level are cleared to zero, the modified vehicle diagnostic description file is output.

[0071] In one embodiment, the modified vehicle diagnostic description file is re-parsed using the same parsing method as before the modification, and the re-parsed diagnostic data is compared again with the diagnostic requirements file. If the differences are cleared, it indicates that the modification is complete and no new deviations have been introduced, and the modified vehicle diagnostic description file is then output. The re-parsing and re-comparison form a verification closed loop, making the modification results traceable and meeting the quality traceability requirements of the mass production stage. If the differences are not cleared, a new difference list is generated based on the remaining differences, and the incremental modification process is executed again until the differences are cleared and then output.

[0072] Specifically, after the modified vehicle diagnostic description file is re-parsed, 642 data identifiers and 328 fault codes are detected. After comparing each item with the diagnostic requirements file, the number of differences is zero, confirming the differences are cleared, and the modified vehicle diagnostic description file is output. The modified vehicle diagnostic description file can be loaded and edited normally by CANdelaStudio 16.0, and all reference relationships remain intact. After being compiled by CANdelaStudio, the modified vehicle diagnostic description file is flashed into the diagnostic configuration area of ​​the electronic control unit, allowing the production line EOL diagnostic instrument to read and perform off-line testing, ensuring that the diagnostic configuration of each off-line vehicle is consistent with the diagnostic requirements file.

[0073] This application provides an automatic modification device for vehicle diagnostic description files, comprising: The acquisition module is used to acquire the target diagnostic object and the vehicle diagnostic description file, wherein the vehicle diagnostic description file includes a diagnostic classification container, and the diagnostic classification container includes diagnostic instances; The determination module is used to determine the target diagnostic category container to which the target diagnostic object belongs based on the combination of service sub-functions of the target diagnostic object in the diagnostic requirements file; The cloning module is used to select a template diagnostic instance in the target diagnostic classification container, clone the template diagnostic instance, and generate a new diagnostic instance corresponding to the target diagnostic object. The template diagnostic instance has attributes including a reference attribute and a unique identifier attribute. The value of the reference attribute points to other objects in the vehicle diagnostic description file, and the value of the unique identifier attribute is the identifier of the diagnostic instance itself. During cloning, the value of the reference attribute remains unchanged, and the value of the unique identifier attribute is replaced with a new identifier. The writing module is used to write the new diagnostic instance into the target diagnostic classification container to obtain the modified vehicle diagnostic description file.

[0074] like Figure 2 As 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 modification method of the vehicle diagnostic description file as described above when the computer program is executed.

[0075] 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: Obtain the target diagnostic object and the vehicle diagnostic description file, wherein the vehicle diagnostic description file includes a diagnostic classification container, and the diagnostic classification container includes diagnostic instances; Based on the combination of service sub-functions of the target diagnostic object in the diagnostic requirements file, determine the target diagnostic category container to which the target diagnostic object belongs; A template diagnostic instance is selected in the target diagnostic classification container, the template diagnostic instance is cloned, and a new diagnostic instance corresponding to the target diagnostic object is generated. The template diagnostic instance has attributes including a reference attribute and a unique identifier attribute. The value of the reference attribute points to other objects in the vehicle diagnostic description file, and the value of the unique identifier attribute is the identifier of the diagnostic instance itself. When cloning, the value of the reference attribute remains unchanged, and the value of the unique identifier attribute is replaced with the new identifier. The new diagnostic instance is written into the target diagnostic classification container to obtain the modified vehicle diagnostic description file.

[0076] 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 modification method for vehicle diagnostic description files as described above.

[0077] 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: Obtain the target diagnostic object and the vehicle diagnostic description file, wherein the vehicle diagnostic description file includes a diagnostic classification container, and the diagnostic classification container includes diagnostic instances; Based on the combination of service sub-functions of the target diagnostic object in the diagnostic requirements file, determine the target diagnostic category container to which the target diagnostic object belongs; A template diagnostic instance is selected in the target diagnostic classification container, the template diagnostic instance is cloned, and a new diagnostic instance corresponding to the target diagnostic object is generated. The template diagnostic instance has attributes including a reference attribute and a unique identifier attribute. The value of the reference attribute points to other objects in the vehicle diagnostic description file, and the value of the unique identifier attribute is the identifier of the diagnostic instance itself. When cloning, the value of the reference attribute remains unchanged, and the value of the unique identifier attribute is replaced with the new identifier. The new diagnostic instance is written into the target diagnostic classification container to obtain the modified vehicle diagnostic description file.

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

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

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

[0081] 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 modifying a vehicle diagnostic description file, characterized in that, include: Obtain the target diagnostic object and the vehicle diagnostic description file, wherein the vehicle diagnostic description file includes a diagnostic classification container, and the diagnostic classification container includes diagnostic instances; Based on the combination of service sub-functions of the target diagnostic object in the diagnostic requirements file, determine the target diagnostic category container to which the target diagnostic object belongs; A template diagnostic instance is selected in the target diagnostic classification container, the template diagnostic instance is cloned, and a new diagnostic instance corresponding to the target diagnostic object is generated. The template diagnostic instance has attributes including a reference attribute and a unique identifier attribute. The value of the reference attribute points to other objects in the vehicle diagnostic description file, and the value of the unique identifier attribute is the identifier of the diagnostic instance itself. When cloning, the value of the reference attribute remains unchanged, and the value of the unique identifier attribute is replaced with the new identifier. The new diagnostic instance is written into the target diagnostic classification container to obtain the modified vehicle diagnostic description file.

2. The method according to claim 1, characterized in that, The target diagnostic object to be acquired includes: Obtain a difference list, which records the attribute differences of the diagnostic object between the diagnostic requirement file and the vehicle diagnostic description file; The target diagnostic object is determined from the list of differences.

3. The method for automatically modifying vehicle diagnostic description files according to claim 1, characterized in that, The step of determining the target diagnostic category container to which the target diagnostic object belongs based on the service sub-function combination of the target diagnostic object in the diagnostic requirements file includes: When the target diagnostic object is a combined data identifier that aggregates multiple sub-data identifiers, the target diagnostic classification container is determined to be an identification information container; When the service sub-function combination includes an input / output control service, the target diagnostic classification container is determined to be an input / output control container; When the service sub-function combination includes both data reading service and data writing service, the target diagnostic classification container is determined to be a variant configuration container. When the service sub-function combination only includes the data reading service, the target diagnostic classification container is determined to be a dynamic data container; When the service sub-function combination only includes the data writing service, the target diagnostic classification container is determined to be a data storage container.

4. The method for automatically modifying vehicle diagnostic description files according to claim 1, characterized in that, The step of replacing the value of the proprietary identifier attribute with the new identifier includes: The attribute names of the template diagnostic instance are matched using a negative lookback regular expression, wherein attribute names ending with a reference identifier are excluded by the negative lookback regular expression. The attribute corresponding to the attribute name that was not excluded is determined as the proprietary identifier attribute, and the assignment position of the proprietary identifier attribute is located in the text of the template diagnostic instance. Replace the value at the assignment position with the new identifier.

5. The method for automatically modifying vehicle diagnostic description files according to claim 1, characterized in that, The method further includes performing at least one of the following editing operations on the vehicle diagnostic description file 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.

6. The method for automatically modifying vehicle diagnostic description files according to claim 1, characterized in that, The method further includes: In the new diagnostic instance, delete the unsupported services indicated by the difference list and the corresponding data object blocks of the unsupported services. After each deletion, rescan the text of the vehicle diagnostic description file to obtain the updated matching position; make subsequent modifications based on the updated matching position.

7. The method for automatically modifying vehicle diagnostic description files according to claim 5, characterized in that, Also includes: The editing operations performed on the vehicle diagnostic description file are sorted in descending order of line number; The editing operations are applied sequentially from the bottom up in the vehicle diagnostic description file.

8. The method for automatically modifying vehicle diagnostic description files according to claim 1, characterized in that, When the target diagnostic object is a fault code, the method further includes: The fault code record corresponding to the fault code is simultaneously written into each fault code record container in the vehicle diagnostic description file, wherein each fault code record container does not include the on-board diagnostic fault code container; the fault code record in each fault code record container has an independent identifier.

9. The method for automatically modifying vehicle diagnostic description files according to claim 1, characterized in that, After obtaining the modified vehicle diagnostic description file, the process also includes: The modified vehicle diagnostic description file is re-parsed, and the diagnostic data obtained from the re-parsed file is compared with the diagnostic requirement file again. After confirming that the differences at the diagnostic object identifier level are cleared to zero, the modified vehicle diagnostic description file is output.

10. An automatic modification device for vehicle diagnostic description files, characterized in that, include: The acquisition module is used to acquire the target diagnostic object and the vehicle diagnostic description file, wherein the vehicle diagnostic description file includes a diagnostic classification container, and the diagnostic classification container includes diagnostic instances; The determination module is used to determine the target diagnostic category container to which the target diagnostic object belongs based on the combination of service sub-functions of the target diagnostic object in the diagnostic requirements file; The cloning module is used to select a template diagnostic instance in the target diagnostic classification container, clone the template diagnostic instance, and generate a new diagnostic instance corresponding to the target diagnostic object. The template diagnostic instance has attributes including a reference attribute and a unique identifier attribute. The value of the reference attribute points to other objects in the vehicle diagnostic description file, and the value of the unique identifier attribute is the identifier of the diagnostic instance itself. During cloning, the value of the reference attribute remains unchanged, and the value of the unique identifier attribute is replaced with a new identifier. The writing module is used to write the new diagnostic instance into the target diagnostic classification container to obtain the modified vehicle diagnostic description file.

Images