Methods, apparatus, storage media, and electronic devices for bidirectional conversion between VCDF and JSON

Abstract

The application provides a bidirectional conversion method and device of VCDF and JSON, a storage medium and an electronic device, and belongs to the technical field of automobile electronics. The method comprises the following steps: opening a target VCDF file in binary mode, reading a byte stream and performing multilayer legality verification, including verifying the file identification, the file length consistency, the data block quantity range and the verification area length consistency; after the verification is passed, the head section, the data block section and the verification area section are parsed according to the fixed structure of VCDF, wherein the head section has a fixed length, the length of each data block in the data block section is determined based on the data length field in the block, and the length of the verification area section is determined based on the data block quantity; the parsed head section, data block section and verification area section are converted into JSON objects respectively, and are combined into a complete JSON file output. By using the application, lossless conversion of VCDF and general JSON format can be realized, the difficulty of calibration data debugging and cross-platform interaction is reduced, and the efficiency and reliability of data processing are improved.

Description

Technical Field

[0001] This invention relates to the field of automotive electronics technology, specifically to a bidirectional conversion method, apparatus, storage medium, and electronic device for VCDF and JSON. Background Technology

[0002] VCDF (Vehicle Calibration Data Format) is a dedicated binary file format used for storing calibration parameters of automotive electronic control units (ECUs). In existing technologies, VCDF files typically organize data as a continuous byte stream, containing a fixed structure including a header segment, data block segment, and checksum segment. Reading and modifying VCDF files requires dedicated calibration tools (such as Vector CANape, ETAS INCA, etc.) or manufacturer-provided parsing libraries. These tools can parse and present the binary byte stream according to predefined internal format definitions. The file embeds both CRC16 and SHA256 checksums, used by the ECU to verify data integrity and tamper-proofing when loading the file. When calibration parameters need to interact with cloud management systems, diagnostic platforms, or Excel software, it is usually necessary to first export the binary data to CSV or text format using a dedicated tool, and then manually import it into the target platform, and vice versa.

[0003] However, the aforementioned existing technologies have at least the following drawbacks: First, VCDF is a proprietary binary format whose field definitions and data structures are not publicly available. Parameters are stored as byte streams without a visual structure, making it impossible to directly view or modify the file content without dedicated parsing tools. When manually modified using a hexadecimal editor, the inability to intuitively perceive field boundaries easily leads to byte misalignment and file structure corruption. Second, when calibration personnel change parameters in the file through non-dedicated means (such as manually modifying the binary or indirectly editing through third-party tools), the embedded CRC16 and SHA256 checksums in the file are not automatically updated. This causes the modified VCDF file to fail verification when loaded into the ECU, resulting in the calibration data being rejected and the entire calibration process being interrupted. Third, in existing technologies, data export from VCDF to general formats often relies on manual operation and format conversion, a cumbersome and error-prone process. This leads to low data interaction efficiency between VCDF files and cloud management systems, diagnostic platforms, and general office software such as Excel, resulting in a high verification failure rate after manual editing. The consistency and reliability of calibration data during cross-system transfer are difficult to guarantee.

[0004] Therefore, how to achieve visualization and editability of VCDF files without relying on dedicated parsing tools, and automatically maintain the consistency of its internal check chain after the file content is modified, while opening up a bidirectional conversion channel between VCDF and general data formats to improve the efficiency and reliability of cross-system interaction of calibration data, is a technical problem that urgently needs to be solved in this field. Summary of the Invention

[0005] In view of this, it is necessary to provide a method, apparatus, storage medium and electronic device for bidirectional conversion between VCDF and JSON, so as to solve the technical problems of low system interaction efficiency and poor reliability caused by the reliance on dedicated parsing tools and the inability of the verification chain to be automatically updated in the existing methods.

[0006] To address the aforementioned technical problems, in a first aspect, the present invention provides a bidirectional conversion method between VCDF and JSON, including the step of converting a VCDF file into JSON format: Open the target VCDF file in binary mode and read its contents to obtain a byte stream. Perform a validity check on the byte stream, the validity check including checking the file identifier, checking the consistency of the file length, checking the range of the number of data blocks, and checking the consistency of the length of the verification area; After the verification is passed, according to the fixed structure of the VCDF file, the data segment is parsed from the byte stream. The data segment includes a header segment, a data block segment and a verification segment. The fixed structure is as follows: the header segment has a fixed length, the data block segment contains several data blocks and the length of each data block is determined based on the data length field within the block, and the length of the verification segment is determined based on the number of data blocks. The parsed header segment, data block segment, and checksum segment are converted into JSON objects respectively, and then combined into a complete JSON file for output.

[0007] In one possible implementation, performing a validity check on the byte stream includes: Verify whether the identifier of the start position of the byte stream is 0xVC0F to obtain the file identifier verification result; The theoretical total length is read from the byte stream and compared with the actual length of the byte stream to obtain the file length consistency check result; Read the number of data blocks and verify whether the number of data blocks is within the range of 1 to 20 to obtain the data block number range verification result.

[0008] In one possible implementation, performing a validity check on the byte stream includes: Obtain the number of data blocks and calculate the theoretical length of the verification area based on the number of data blocks; Read the actual length of the verification area from the predetermined position in the byte stream; Determine whether the actual length of the verification area is equal to the theoretical length of the verification area; if not, terminate the conversion.

[0009] In one possible implementation, parsing data segments from the byte stream according to the fixed structure of the VCDF file includes: When parsing the data block segment, the number of iterations is determined based on the number of data blocks. In each loop, parse the current data block and get the length of the current data block; Update the read pointer position based on the length of the current data block until all data blocks have been parsed.

[0010] In one possible implementation, parsing data segments from the byte stream according to the fixed structure of the VCDF file includes: When parsing the verification section, the current parsing position is obtained, and the pre-stored verification section offset field is read from the header section; The current parsing position is compared with the verification area offset field. If the comparison results are inconsistent, the conversion is terminated.

[0011] This invention also provides a bidirectional conversion method between VCDF and JSON, including the step of converting a JSON file to VCDF format: Obtain the JSON file to be converted, and perform structural validation on the JSON file to confirm that it contains a header node, a data block list node, and a validation area node; Extract context parameters from the JSON file, including the number of data blocks, the data length of each data block, and compression flags; Based on the context parameters, the hexadecimal string in the JSON node is restored to a binary byte stream, and the header segment, data block segment, and check segment are reconstructed. During the reconstruction process, the CRC16 check value of each data block, the SHA256 hash value of each data block, and the SHA256 hash value of the complete check segment are automatically recalculated based on the context parameters, and the calculated check values ​​are written into the corresponding fields. Based on the actual length of each segment after reconstruction, the total file length and checksum offset are automatically calculated and updated to the header segment; The header segment, data block segment, and check segment are concatenated in sequence to output a VCDF file.

[0012] In one possible implementation, based on the context parameters, the hexadecimal string in the JSON node is restored to a binary byte stream, reconstructing the header segment, data block segment, and checksum segment, including: When reconstructing the verification section, the total length of the verification section is determined to be equal to 4 plus the number of data blocks multiplied by 40; The binary data is concatenated according to the format identifier of the check area, the total number of check blocks, and the order of each hash entry to obtain the binary segment of the check area; After obtaining the complete binary byte stream, remove consecutive bytes. a The cleaned byte stream is obtained by adding one or more 0x00 bytes and all 0xFF redundant bytes. a The first preset threshold; Calculate the percentage of valid data in the cleaned byte stream. If the percentage of valid data is less than... b Then the conversion will terminate. b This is the second preset threshold.

[0013] On the other hand, the present invention also provides a bidirectional conversion device between VCDF and JSON, comprising: The read module is used to open VCDF files in binary mode and read byte streams. The validation module is used to perform validity or structure checks during the bidirectional conversion between VCDF and JSON. The parsing module is used to parse VCDF files into JSON objects; The refactoring module is used to refactor JSON objects into VCDF files; The output module is used to output the converted JSON file or VCDF file.

[0014] Thirdly, the present invention also provides an electronic device, including a file reading interface, a network interface, a memory, and a processor, wherein... The file reading interface is connected to the processor and is used to read the target VCDF file from the external storage medium in binary read-only mode, and transmit the read byte stream to the processor as a data source; The network interface is connected to the processor and is used to receive a JSON file to be converted sent by an external device and transmit the JSON file to the processor as a data source; The memory is used to store programs; The processor, coupled to the memory, is used to execute the program stored in the memory to implement the steps in the bidirectional conversion method between VCDF and JSON described in any of the above implementations.

[0015] Fourthly, the present invention also provides a computer-readable storage medium for storing a computer-readable program or instruction, which, when executed by a processor, is capable of implementing the steps in the bidirectional conversion method between VCDF and JSON described in any of the above implementations.

[0016] The beneficial effects of this invention are as follows: The bidirectional conversion method between VCDF and JSON provided by this invention reads the content of a VCDF file in binary mode and performs multi-layered validity checks on file identification, length consistency, data block quantity range, and checksum length. This ensures that subsequent parsing is based on a structurally complete file, avoiding parsing anomalies caused by file corruption or format errors. After successful verification, the VCDF file is parsed segment by segment according to its fixed header, data block, and checksum structure, and each segment is converted into a JSON object. This transforms the originally invisible binary data into a clearly structured and editable text, improving the readability and ease of operation of VCDF files during debugging and cross-platform interaction, and reducing the risk of byte misalignment during manual editing. This method solves the problems of existing technologies that rely on dedicated parsing tools and cannot automatically maintain the checksum chain, improving the efficiency and reliability of data interaction between VCDF files and general platforms. Attached Figure Description

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

[0018] Figure 1 A schematic flowchart of an embodiment of the bidirectional conversion method between VCDF and JSON provided by the present invention; Figure 2 For the present invention Figure 1 A schematic diagram of an embodiment of S102; Figure 3 For the present invention Figure 1 A schematic diagram of another embodiment of S102; Figure 4 For the present invention Figure 1 A schematic diagram of an embodiment of S103; Figure 5 For the present invention Figure 1 A schematic diagram of another embodiment of S103; Figure 6 A schematic flowchart of another embodiment of the bidirectional conversion method between VCDF and JSON provided by the present invention; Figure 7 For the present invention Figure 6 A schematic diagram of an embodiment of S603; Figure 8 A schematic diagram of an embodiment of the bidirectional conversion device between VCDF and JSON provided by the present invention; Figure 9 A schematic diagram of an embodiment of the electronic device provided by the present invention. Detailed Implementation

[0019] In the description of the embodiments of the present invention, unless otherwise stated, "multiple" means two or more. "And / or" describes the relationship between related objects, indicating that there can be three relationships. For example, A and / or B can represent three situations: A exists alone, A and B exist simultaneously, and B exists alone.

[0020] The terms "first," "second," etc., used in the embodiments of this invention are for descriptive purposes only and should not be construed as indicating or implying their relative importance or implicitly specifying the number of technical features indicated. Therefore, a technical feature defined with "first" or "second" may explicitly or implicitly include at least one of that feature.

[0021] In this document, the term "embodiment" means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of the invention. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

[0022] This invention provides a method, apparatus, storage medium, and electronic device for bidirectional conversion between VCDF and JSON. The technical solutions of the embodiments of this invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this invention. All other embodiments obtained by those skilled in the art based on the embodiments of this invention without creative effort are within the scope of protection of this invention.

[0023] Figure 1 The following is a flowchart illustrating an embodiment of the bidirectional conversion method between VCDF and JSON provided by the present invention, as shown below. Figure 1 As shown, this bidirectional conversion method between VCDF and JSON includes the following steps to convert a VCDF file to JSON format: S101. Open the target VCDF file in binary mode and read the file content to obtain a byte stream.

[0024] Specifically, the host computer tool calls the file operation interface provided by the operating system to open the VCDF file to be converted in binary read-only mode, reads all the contents of the file byte by byte into the memory buffer, forming a continuous byte stream, and records the actual length of the byte stream, denoted as Act_Len.

[0025] For example, assuming the target VCDF file is 1024 bytes in size, after reading it, a byte array of length 1024 is obtained. All subsequent parsing operations are based on this byte array in memory, avoiding repeated reading of the disk file.

[0026] S102. Perform a validity check on the byte stream. The validity check includes checking the file identifier, checking the consistency of the file length, checking the range of the number of data blocks, and checking the consistency of the length of the verification area.

[0027] Specifically, after reading the file content, multiple basic validity checks are immediately performed on the byte stream to ensure that the file to be converted conforms to the basic specifications of the VCDF format. This verification process is a prerequisite for subsequent parsing; if any check fails, the conversion is terminated and a structure error message is returned.

[0028] S103. After the verification is passed, according to the fixed structure of the VCDF file, the data segment is parsed from the byte stream. The data segment includes a header segment, a data block segment, and a verification segment. The fixed structure is as follows: the header segment has a fixed length, the data block segment contains several data blocks and the length of each data block is determined based on the data length field within the block, and the length of the verification segment is determined based on the number of data blocks.

[0029] It should be noted that, in a specific example, the fixed structure of a VCDF file is as follows: the header segment is a fixed length of 570 bytes, which contains metadata such as file identifier, version information, and identification identifier; the data block segment is located after the header segment and contains several VCDF data blocks. The length of each data block is not a fixed value, but is dynamically determined based on the data length field within the block, and the blocks are closely connected; the check segment is located at the end of the file, and its length is dynamically determined based on the number of data blocks. It is used to store the hash check information of each data block.

[0030] S104. Convert the parsed header segment, data block segment, and checksum segment into JSON objects respectively, and combine them into a complete JSON file for output.

[0031] Specifically, each field in the header section is converted into key-value pairs of JSON objects according to predefined field names. Data blocks in the data block section are stored in a JSON array in the parsing order, and hash entries in the validation section are also stored in a JSON array in order. The final output JSON file has the same name as the original VCDF file, but with the suffix changed to .json, and a conversion log is generated to record the conversion status.

[0032] In one specific implementation of this embodiment, the header segment is decomposed according to a fixed offset and field length predefined in the VCDF format.

[0033] Specifically, from the 570 bytes at offsets 0 to 569 in the byte stream, the following fields are extracted sequentially: offsets 0-1 are the file identifier `vcdf_magic`, offsets 2-5 are the format version `format_ver`, offsets 6-9 are the calibration identifier `cal_id`, offsets 10-13 are the electronic control unit part number `ecu_part_num`, offsets 14-17 are the total length `total_length`, offsets 18-21 are the number of data blocks `vcdb_count`, offsets 22-23 are the checksum offset `vct_offset`, offsets 24-25 are the checksum length `vct_length`, offsets 26-57 are the checksum hash `vct_hash`, offsets 58-313 are the device signature `dev_signature`, and offsets 314-569 are the product signature `prod_signature`. Each field is converted from raw binary bytes to hexadecimal strings starting with 0x, maintaining the same byte order and length, and a JSON header object is constructed using the original field names.

[0034] By using the above method, we can ensure that every parameter in the header segment has a clear corresponding key-value pair in the JSON file, which facilitates subsequent manual viewing and editing.

[0035] In this embodiment, a conversion log is generated after the VCDF to JSON conversion is completed. This log records the following information: the actual length of the original VCDF file, the number of parsed data blocks N, the length of the VCT verification area, whether each verification step passed, and the final parsing status (success or failure). The log is stored as a text file in the same directory as the output JSON file, facilitating user tracking of the conversion process and troubleshooting.

[0036] In this embodiment, the originally invisible binary VCDF file is converted into a well-structured, readable, and editable JSON text file. Calibration engineers can view and modify calibration parameters without relying on dedicated parsing tools, reducing the debugging threshold and the risk of byte misalignment during editing.

[0037] In some embodiments of the present invention, such as Figure 2 As shown, step S102, which performs a validity check on the byte stream, includes: S201. Verify whether the identifier of the start position of the byte stream is 0xVC0F to obtain the file identifier verification result; S202. Read the theoretical total length from the byte stream and compare it with the actual length of the byte stream to obtain the file length consistency check result; S203. Read the number of data blocks, verify whether the number of data blocks is within the range of 1 to 20, and obtain the data block number range verification result.

[0038] Specifically, the fixed format of VCDF files requires the first two bytes of the file to be a fixed magic word 0xVC0F, which is used to distinguish VCDF files from other binary files.

[0039] In this embodiment, 2 bytes of content are read from offset 0 of the byte stream, and it is determined whether the value is equal to 0xVC0F. If they are not equal, the file is directly determined to be in non-standard VCDF format, the conversion is terminated, and a format error message is returned.

[0040] Further, 4 bytes of content are read from offset 14 to offset 17 of the byte stream and parsed into a theoretical total length field, denoted as total_length. This theoretical total length is then completely compared with the actual file length Act_Len obtained in step S101. If the two are not equal, it indicates that the file has been truncated, padded, or tampered with, and the conversion is terminated and a length mismatch message is returned.

[0041] Furthermore, 4 bytes of content are read from offset 18 to offset 21 of the byte stream, parsed into the number of data blocks, denoted as . N According to the VCDF format specification, the number of data blocks... N Must satisfy 1≤ N If the value is ≤20, and exceeds this range, the format is considered abnormal and the conversion is terminated. For example, if the read value is ≤20, the conversion will be terminated. N If the value is 0 or 25, the validation fails.

[0042] In some embodiments of the present invention, invalid byte information is recorded synchronously during the conversion process.

[0043] Specifically, during the byte-by-byte parsing of the VCDF file, regions containing 16 or more consecutive 0x00 bytes and pure 0xFF redundant bytes are marked, and the starting offset and length of these invalid regions are recorded. This redundancy information is written to the final output JSON object as additional fields, such as adding a "redundant_info" array under the root node, with each element containing "offset" and "length" fields. This allows users to intuitively understand which regions in the original file belong to padding bytes when editing the JSON file, avoiding accidental modification of valid data areas. Furthermore, when converting the JSON back to VCDF, this redundancy information can be used to decide whether to remove or retain the corresponding padding bytes.

[0044] Through the above three checks, this embodiment can effectively identify problems such as file format errors, abnormal lengths, and out-of-bounds parameters before parsing, avoiding program crashes or erroneous outputs caused by data abnormalities during subsequent parsing, and improving the stability of the conversion process.

[0045] In some embodiments of the present invention, such as Figure 3As shown, step S102 performs a validity check on the byte stream, including: S301. Obtain the number of data blocks and calculate the theoretical length of the check area based on the number of data blocks.

[0046] Specifically, first, the number of data blocks N is read from the byte stream (this value is the same as N obtained in step S203), and then the theoretical length of the VCT checksum area is calculated according to the VCDF format definition. The specific calculation formula is: L_VCT = 4 + N × 40.

[0047] Here, the constant 4 corresponds to the total length of the two fields, vct_format (2 bytes) and vcdb_total (2 bytes), in the VCT checksum area. N ×40 indicates N The total length of each hash entry is 40 bytes (containing a 4-byte address, a 4-byte length, and a 32-byte hash value).

[0048] S302. Read the actual length of the check area from the predetermined position of the byte stream.

[0049] Specifically, 2 bytes of content are read from the position between offset 24 and offset 25 of the byte stream, and parsed into the actual length field of the check area, denoted as vct_length.

[0050] S303. Determine whether the actual length of the verification area is equal to the theoretical length of the verification area. If not, terminate the conversion.

[0051] Specifically, the vct_length read from the file is compared with the calculated L_VCT. If the two are inconsistent, it indicates that the file structure is misaligned, there are missing or out-of-order bytes, and the system refuses to continue parsing and returns a structure error message.

[0052] It should be noted that this verification can effectively identify file structure corruption caused by manual editing or transmission errors, ensuring the reliability of subsequent parsing.

[0053] In some embodiments of the present invention, such as Figure 4 As shown, step S103 parses data segments from the byte stream according to the fixed structure of the VCDF file, including: S401. When parsing a data block segment, the number of iterations is determined based on the number of data blocks.

[0054] Specifically, after the header segment is parsed, the byte read pointer is positioned at offset 570 (i.e., the end of the header segment), which is the starting address of the first VCDB data block. This is based on the number of data blocks previously obtained. N The number of loops to be executed is determined as follows. N .

[0055] S402. In each loop, parse the current data block and get the length of the current data block.

[0056] Specifically, each loop first reads 2 bytes from the current pointer position as the block identifier (block_id), then reads 1 byte as the compression flag (compress_flag), then reads 4 bytes as the data length (data_len), and continues reading bytes of the corresponding length as the block data (vcdb_data) based on the value of data_len. Finally, it reads 2 bytes as the block checksum (vcdb_crc16). Based on these fields, the total length of the current data block can be calculated as: 2 (block_id) + 1 (compress_flag) + 4 (data_len) + data_len + 2 (vcdb_crc16).

[0057] S403. Update the read pointer position according to the length of the current data block until all data blocks have been parsed.

[0058] Specifically, after parsing each data block, the read pointer is advanced forward by the total length of the current data block, so that the pointer points to the beginning of the next data block, and then the next loop continues.

[0059] For example, assuming the first data block has a data_len of 100 bytes, the total length of that block is 109 bytes. After parsing, the pointer moves forward 109 bytes to point to the beginning of the second data block. This pointer advancement method ensures that each data block is parsed correctly and consecutively, avoiding byte misalignment.

[0060] In some embodiments of the present invention, such as Figure 5 As shown, step S103 parses data segments from the byte stream according to the fixed structure of the VCDF file, including: S501. When parsing the check segment, obtain the current parsing position and read the pre-stored check segment offset field from the header segment.

[0061] Specifically, after all VCDB data blocks have been parsed, the current read pointer position is the starting address of the VCT checksum area, denoted as VCT_Start. Simultaneously, the vct_offset field is read from the previously parsed header segment; this field records the theoretical starting offset value of the VCT checksum area in the VCDF file format definition.

[0062] S502. Compare the current parsing position with the check area offset field. If the comparison results are inconsistent, terminate the conversion.

[0063] Specifically, VCT_Start is compared with vct_offset. If they do not match, it indicates a length calculation error or byte parsing misalignment occurred during data block parsing. In this case, the conversion is terminated and a position mismatch message is returned. If they match, the parsing of the VCT checksum continues. This check serves as a final confirmation of the preceding parsing process, further ensuring the accuracy of the parsing.

[0064] Figure 6 The following is a flowchart illustrating an embodiment of the bidirectional conversion method between VCDF and JSON provided by the present invention, as shown below. Figure 6 As shown, this bidirectional conversion method between VCDF and JSON includes the following steps to convert JSON format into a VCDF file: S601. Obtain the JSON file to be converted, perform structure validation on the JSON file, and confirm that it contains header nodes, data block list nodes, and validation area nodes.

[0065] Specifically, the host computer tool reads the JSON file specified by the user, parses its top-level structure, and verifies whether it contains three fixed nodes: VCDF_Header, VCDB_List, and VCT. If any node is missing, the structure is deemed invalid and the conversion is terminated.

[0066] S602. Extract context parameters from the JSON file. The context parameters include the number of data blocks, the data length of each data block, and the compression flag.

[0067] Specifically, the vcdb_count field is read from the VCDF_Header node and denoted as N, with N checked to be within the range of 1 to 20; the data_len and compress_flag fields of each data block are obtained from the VCDB_List node. These parameters will be used for subsequent binary reconstruction and checksum calculation.

[0068] Before performing step S602, this embodiment also performs fine-grained validation on the data in the JSON file.

[0069] First, each data block in the data block list node is individually validated: ensuring the data length field `data_len` is greater than or equal to 1, the compression flag `compress_flag` can only be 0 or 1, and the actual byte length of the block data `vcdb_data` matches the value of the `data_len` field. If they do not match, the conversion is terminated and a data block format error is indicated. Second, all hexadecimal format strings in the JSON file are checked for validity, ensuring that each string begins with "0x", the character range only includes 0-9, AF, and af, and the string length conforms to the definition of the corresponding field (e.g., `block_id` is fixed at 4 hexadecimal characters, and `vct_hash` is fixed at 64 hexadecimal characters). Any format error stops the conversion and the location of the abnormal field is explicitly indicated. This double validation effectively avoids binary reconstruction failures caused by JSON editing errors.

[0070] S603. Based on the context parameters, restore the hexadecimal string in the JSON node to a binary byte stream, reconstruct the header segment, data block segment, and check segment. During the reconstruction process, automatically recalculate the CRC16 check value of each data block, the SHA256 hash value of each data block, and the SHA256 hash value of the complete check segment based on the context parameters, and write the calculated check values ​​into the corresponding fields.

[0071] It should be noted that the CRC16 algorithm uses a polynomial of 0x8005 and an initial value of 0xFFFF for calculation. The SHA256 hash value is calculated as follows: if `compress_flag` is 1, `vcdb_data` is first decompressed, and the hash is calculated using the decompressed original data; if `compress_flag` is 0, `vcdb_data` is used directly to calculate the hash.

[0072] S604. Based on the actual length of each segment after reconstruction, automatically calculate the total file length and checksum offset, and update them to the header segment.

[0073] Specifically, the total length of all concatenated VCDB data blocks, Sum_VCDB_Len, is calculated. The check offset, vct_offset, is calculated as 570 + Sum_VCDB_Len. The total file length, total_length, is calculated as 570 + Sum_VCDB_Len + (4 + N × 40). These automatically derived values ​​are written to the corresponding field positions in the header segment to ensure that the file length, offset, and structure are completely consistent.

[0074] S605. Concatenate the header segment, data block segment, and check segment in sequence to output a VCDF file.

[0075] Specifically, the VCDF_Header, VCDB_ALL, and VCT bytes are concatenated into a complete binary byte stream without gaps or padding, and the output is a file with the .vcdf extension. The filename is composed of cal_id and a timestamp to ensure uniqueness and traceability. A write-back log is also generated to record the checksum update results and file length information.

[0076] Correspondingly, a write-back log is generated after the JSON to VCDF conversion is completed. The write-back log records edited modifications (such as which fields were manually changed by the user), the results of checksum recalculation (new CRC16 and SHA256 hash values ​​for each data block), the number of redundant bytes cleaned up, the final length of the generated VCDF file, and the ECU adaptation status. By using the write-back log, it is confirmed whether the conversion process meets expectations and the cause can be quickly located when anomalies occur in the calibration data.

[0077] Through the above method, this embodiment realizes the reverse conversion from JSON to VCDF, and automatically completes the reconstruction of the verification chain during the conversion process, ensuring that the output file can directly pass the ECU's verification and solving the technical problem of verification failure after manual editing.

[0078] In some embodiments of the present invention, such as Figure 7 As shown, step S603, based on the context parameters, restores the hexadecimal string in the JSON node to a binary byte stream, reconstructing the header segment, data block segment, and checksum segment, including: S701. When reconstructing the check segment, the total length of the check segment is determined to be equal to 4 plus the number of data blocks multiplied by 40. S702. Concatenate binary data according to the format identifier of the check area, the total number of check blocks, and the order of each hash entry to obtain the binary segment of the check area; S703. After obtaining the complete binary byte stream, remove consecutive bytes. a The cleaned byte stream is obtained by adding one or more 0x00 bytes and all 0xFF redundant bytes. a The first preset threshold; S704. Calculate the percentage of valid data in the cleaned byte stream. If the percentage of valid data is less than... b Then the conversion will terminate. b This is the second preset threshold.

[0079] The above step S603, when reconstructing the verification section, also includes redundant data cleanup and validity verification. This embodiment provides a specific implementation process for the verification section reconstruction and optimization.

[0080] Specifically, based on the number of data blocks N, the total length of the check segment is strictly equal to 4 + N × 40, where the first 4 bytes are vct_format (2 bytes) and vcdb_total (2 bytes), followed by N 40-byte hash entries.

[0081] The binary data is concatenated according to the format identifier of the check area, the total number of check blocks, and the order of each hash entry to obtain the check area binary segment. Specifically, first, the vct_format and vcdb_total fields are obtained from the JSON and converted into binary bytes; then, the hash_list array is traversed, and the vcdb_addr (4 bytes), vcdb_len (4 bytes), and vcdb_hash (32 bytes) in each hash entry are concatenated in order to form the complete check area binary segment.

[0082] After obtaining the complete binary byte stream, remove consecutive bytes. a The cleaned byte stream is obtained by adding one or more 0x00 bytes and all 0xFF redundant bytes. a The first preset threshold is used. As a preferred embodiment, in this case... a The value is 16.

[0083] It should be understood that VCDF files may contain redundant padding bytes due to historical reasons. This invalid data not only occupies storage space but may also affect the ECU's parsing efficiency. By scanning and removing 16 or more consecutive 0x00 bytes and all 0xFF redundant bytes, the output file can be made more compact.

[0084] The second preset threshold can be set according to actual needs. As a preferred method, the second preset threshold b is set to 98% in this embodiment.

[0085] Specifically, the formula for calculating the percentage of valid data η is as follows: η = Effective length / Total length × 100%. If η If the padding percentage is less than 98%, it indicates that the JSON file contains a large amount of invalid padding, and the generated VCDF file may have structural problems. In this case, the conversion is terminated, and the user is prompted to re-edit the JSON file. This validation ensures the quality of the output file, which helps improve the ECU's efficiency in parsing calibration files.

[0086] To better implement the bidirectional conversion method between VCDF and JSON in this embodiment of the invention, based on the bidirectional conversion method between VCDF and JSON, the corresponding method is as follows: Figure 8 As shown, this embodiment of the invention also provides a bidirectional conversion device for VCDF and JSON. The bidirectional conversion device 800 for VCDF and JSON includes: Read module 801 is used to open a VCDF file in binary mode and read the byte stream; The validation module 802 is used to perform validity or structure validation in the bidirectional conversion between VCDF and JSON. Parsing module 803 is used to parse VCDF files into JSON objects; Refactoring module 804 is used to refactor JSON objects into VCDF files; Output module 805 is used to output the converted JSON file or VCDF file.

[0087] The VCDF to JSON bidirectional conversion device 800 provided in the above embodiments can realize the technical solutions described in the above VCDF to JSON bidirectional conversion method embodiments. The specific implementation principles of each module or unit can be found in the corresponding content of the above VCDF to JSON bidirectional conversion method embodiments, and will not be repeated here.

[0088] like Figure 9 As shown, the present invention also provides an electronic device 900. The electronic device 900 includes a processor 901, a memory 902, a display 903, a file reading interface 904, and a network interface 905. Figure 9 Only some components of the electronic device 900 are shown, but it should be understood that it is not required to implement all of the components shown, and more or fewer components may be implemented instead.

[0089] In some embodiments, processor 901 may be a central processing unit (CPU), microprocessor, or other data processing chip, used to run program code stored in memory 902 or process data, such as the bidirectional conversion method between VCDF and JSON in this invention.

[0090] In some embodiments, processor 901 may be a single server or a group of servers. The server group may be centralized or distributed. In some embodiments, processor 901 may be local or remote. In some embodiments, processor 901 may be implemented on a cloud platform. In one embodiment, the cloud platform may include a private cloud, public cloud, hybrid cloud, community cloud, distributed cloud, internal cloud, multi-cloud, etc., or any combination thereof.

[0091] In some embodiments, memory 902 may be an internal storage unit of electronic device 900, such as a hard disk or memory of electronic device 900. In other embodiments, memory 902 may also be an external storage device of electronic device 900, such as a plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, etc. equipped on electronic device 900.

[0092] Furthermore, the memory 902 may include both internal storage units of the electronic device 900 and external storage devices. The memory 902 is used to store application software and various types of data installed on the electronic device 900.

[0093] In some embodiments, display 903 may be an LED display, a liquid crystal display, a touch-sensitive liquid crystal display, or an OLED (Organic Light-Emitting Diode) touchscreen, etc. Display 903 is used to display information from electronic device 900 and to display a visual user interface.

[0094] The file read interface 904, in some embodiments, may be a Serial Peripheral Interface (SPI), an Integrated Circuit Bus Interface (I²C), or a Universal Asynchronous Receiver / Transmitter Interface (UART) for data interaction with external storage media (such as SD cards, EEPROMs, and flash memory chips). The file read interface 904 reads the target VCDF file stored in the external storage medium in binary read-only mode and transmits the read byte stream to the processor 901 as the data source for the VCDF-to-JSON conversion method.

[0095] The network interface 905 may be a wired or wireless network interface in some embodiments, including but not limited to an Ethernet interface, a Wi-Fi module, a Bluetooth module, and a cellular mobile communication module (such as 4G or 5G). The network interface 905 is used to receive JSON files to be converted sent by a cloud server, a diagnostic platform, or other external devices, and transmit the received JSON files to the processor 901 as the data source for the JSON to VCDF conversion method.

[0096] In one embodiment, when processor 901 executes the bidirectional conversion program between VCDF and JSON in memory 902, the following steps can be implemented: Open the target VCDF file in binary mode and read its contents to obtain a byte stream. Perform a validity check on the byte stream, the validity check including checking the file identifier, checking the consistency of the file length, checking the range of the number of data blocks, and checking the consistency of the length of the verification area; After the verification is passed, according to the fixed structure of the VCDF file, the data segment is parsed from the byte stream. The data segment includes a header segment, a data block segment and a verification segment. The fixed structure is as follows: the header segment has a fixed length, the data block segment contains several data blocks and the length of each data block is determined based on the data length field within the block, and the length of the verification segment is determined based on the number of data blocks. The parsed header segment, data block segment, and checksum segment are converted into JSON objects respectively, and then combined into a complete JSON file for output.

[0097] It should be understood that when the processor 901 executes the bidirectional conversion program between VCDF and JSON in the memory 902, in addition to the functions mentioned above, it can also perform other functions, as detailed in the description of the corresponding method embodiments above.

[0098] Furthermore, the embodiments of the present invention do not specifically limit the type of the electronic device 900 mentioned. The electronic device 900 can be a mobile phone, tablet computer, personal digital assistant (PDA), wearable device, laptop computer, or other portable electronic device. Exemplary embodiments of portable electronic devices include, but are not limited to, portable electronic devices running iOS, Android, Microsoft, or other operating systems. The aforementioned portable electronic device can also be other portable electronic devices, such as a laptop computer with a touch-sensitive surface (e.g., a touch panel). It should also be understood that in some other embodiments of the present invention, the electronic device 900 may not be a portable electronic device, but rather a desktop computer with a touch-sensitive surface (e.g., a touch panel).

[0099] Accordingly, this application also provides a computer-readable storage medium for storing computer-readable programs or instructions. When the programs or instructions are executed by a processor, they can implement the steps or functions of the bidirectional conversion method between VCDF and JSON provided in the above-described method embodiments.

[0100] Those skilled in the art will understand that all or part of the processes of the methods described in the above embodiments can be implemented by a computer program instructing related hardware (such as a processor, controller, etc.), and the computer program can be stored in a computer-readable storage medium. The computer-readable storage medium may be a disk, optical disk, read-only memory, or random access memory, etc.

[0101] The foregoing has provided a detailed description of the bidirectional conversion method, apparatus, storage medium, and electronic device for VCDF and JSON provided by this invention. Specific examples have been used to illustrate the principles and implementation methods of this invention. The descriptions of the above embodiments are only for the purpose of helping to understand the method and core ideas of this invention. At the same time, those skilled in the art will recognize that there will be changes in the specific implementation methods and application scope based on the ideas of this invention. Therefore, the content of this specification should not be construed as a limitation of this invention.

Claims

1. A bidirectional conversion method between VCDF and JSON, characterized in that, This includes the steps of converting VCDF files to JSON format: Open the target VCDF file in binary mode and read its contents to obtain a byte stream. Perform a validity check on the byte stream, the validity check including checking the file identifier, checking the consistency of the file length, checking the range of the number of data blocks, and checking the consistency of the length of the verification area; After the verification is passed, according to the fixed structure of the VCDF file, the data segment is parsed from the byte stream. The data segment includes a header segment, a data block segment, and a verification segment. The fixed structure is as follows: the header segment has a fixed length, the data block segment contains several data blocks and the length of each data block is determined based on the data length field within the block, and the length of the verification segment is determined based on the number of data blocks. The parsed header segment, data block segment, and checksum segment are converted into JSON objects respectively, and then combined into a complete JSON file for output.

2. The method according to claim 1, characterized in that, Performing a validity check on the byte stream includes: Verify whether the identifier of the start position of the byte stream is 0xVC0F to obtain the file identifier verification result; The theoretical total length is read from the byte stream and compared with the actual length of the byte stream to obtain the file length consistency check result; Read the number of data blocks and verify whether the number of data blocks is within the range of 1 to 20 to obtain the data block number range verification result.

3. The method according to claim 1, characterized in that, Performing a validity check on the byte stream includes: Obtain the number of data blocks and calculate the theoretical length of the verification area based on the number of data blocks; Read the actual length of the verification area from the predetermined position in the byte stream; Determine whether the actual length of the verification area is equal to the theoretical length of the verification area; if not, terminate the conversion.

4. The method according to claim 1, characterized in that, The step of parsing data segments from the byte stream according to the fixed structure of the VCDF file includes: When parsing the data block segment, the number of iterations is determined based on the number of data blocks. In each loop, parse the current data block and get the length of the current data block; Update the read pointer position based on the length of the current data block until all data blocks have been parsed.

5. The method according to claim 1, characterized in that, The step of parsing data segments from the byte stream according to the fixed structure of the VCDF file includes: When parsing the verification section, the current parsing position is obtained, and the pre-stored verification section offset field is read from the header section; The current parsing position is compared with the verification area offset field. If the comparison results are inconsistent, the conversion is terminated.

6. A bidirectional conversion method between VCDF and JSON, characterized in that, This includes the steps of converting JSON format to a VCDF file: Obtain the JSON file to be converted, and perform structural validation on the JSON file to confirm that it contains a header node, a data block list node, and a validation area node; Extract context parameters from the JSON file, including the number of data blocks, the data length of each data block, and compression flags; Based on the context parameters, the hexadecimal string in the JSON node is restored to a binary byte stream, and the header segment, data block segment, and check segment are reconstructed. During the reconstruction process, the CRC16 check value of each data block, the SHA256 hash value of each data block, and the SHA256 hash value of the complete check segment are automatically recalculated based on the context parameters, and the calculated check values ​​are written into the corresponding fields. Based on the actual length of each segment after reconstruction, the total file length and checksum offset are automatically calculated and updated to the header segment; The header segment, data block segment, and check segment are concatenated in sequence to output a VCDF file.

7. The method according to claim 6, characterized in that, Based on the context parameters, the hexadecimal string in the JSON node is restored to a binary byte stream, and the header segment, data block segment, and checksum segment are reconstructed, including: When reconstructing the verification section, the total length of the verification section is determined to be equal to 4 plus the number of data blocks multiplied by 40; The binary data is concatenated according to the format identifier of the check area, the total number of check blocks, and the order of each hash entry to obtain the binary segment of the check area; After obtaining the complete binary byte stream, remove consecutive bytes. a The cleaned-up byte stream is obtained by adding one or more 0x00 bytes and all 0xFF redundant bytes. a The first preset threshold; Calculate the percentage of valid data in the cleaned byte stream. If the percentage of valid data is less than... b Then the conversion will terminate. b This is the second preset threshold.

8. A bidirectional conversion device for VCDF files and JSON format, characterized in that, include: The read module is used to open VCDF files in binary mode and read byte streams. The verification module is used to perform the legality verification in the bidirectional conversion method of VCDF and JSON as described in any one of claims 1 to 5, or to perform the structure verification in the bidirectional conversion method of VCDF and JSON as described in claim 6 or 7. The parsing module is used to perform the step of parsing a VCDF file into a JSON object in the bidirectional conversion method between VCDF and JSON as described in any one of claims 1 to 5; The reconstruction module is used to perform the step of reconstructing the JSON object into a VCDF file in the bidirectional conversion method between VCDF and JSON as described in claim 6 or 7. The output module is used to output the converted JSON file or VCDF file.

9. An electronic device, characterized in that, This includes a file read interface, a network interface, memory, and a processor. The file reading interface is connected to the processor and is used to read the target VCDF file from the external storage medium in binary read-only mode, and transmit the read byte stream to the processor as a data source; The network interface is connected to the processor and is used to receive a JSON file to be converted sent by an external device and transmit the JSON file to the processor as a data source; The memory is used to store programs; The processor, coupled to the memory, is used to execute the program stored in the memory to implement the steps in the bidirectional conversion method between VCDF and JSON as described in any one of claims 1 to 7.

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

Images