Ecus upgrade package processing method and system

Abstract

The application discloses an ECU upgrade package processing method and system, comprising the following steps: downloading an ECU upgrade package from a cloud server to a local database, performing block encryption on the ECU upgrade package downloaded to the local database, obtaining a plurality of data blocks and encryption information corresponding to each data block, entering an ECU flashing task, dynamically positioning the corresponding data block according to an offset requested by the ECU, decrypting the data block based on the encryption information, sending the decrypted data block to the ECU, and sending all the data blocks to the ECU. When the ECU upgrade package is flashed, the application can support encrypted storage of the ECU upgrade package, prevent the ECU upgrade package from being stored in the local database of a diagnostic instrument in a plaintext form, and dynamically decrypt the ECU upgrade package, so that the memory occupation of decryption is low, and the memory pressure of the ECU flashing is small.

Description

Technical Field

[0001] This invention relates to the field of automotive diagnostic technology, specifically to a method and system for processing ECU upgrade packages. Background Technology

[0002] In the field of automotive aftermarket diagnostics, ECU (Electronic Control Unit) software upgrades are one of the core functions of diagnostic tools. As vehicles become increasingly intelligent, ECU firmware sizes are growing rapidly (e.g., infotainment system DHU firmware can reach several gigabytes), making the download and flashing efficiency of upgrade packages a key factor affecting the aftermarket repair experience.

[0003] In existing technologies, the downloading and flashing of ECU upgrade packages mainly present the following technical problems: Traditional flashing mechanisms require the complete download of the upgrade package before flashing can begin, and the entire upgrade package must be decrypted during flashing, making on-demand decryption impossible. Memory usage is directly proportional to the size of the upgrade package, limiting the diagnostic tool's ability to flash large-capacity ECUs. For upgrade packages of several gigabytes in size, the diagnostic tool's memory resources are insufficient, easily leading to flashing failures or system crashes. Summary of the Invention

[0004] To address the problems existing in the prior art, this invention provides an ECU upgrade package processing method and system. When flashing the ECU upgrade package, the ECU upgrade package is encrypted and stored to avoid information leakage caused by storing the ECU upgrade package in plaintext in the local database of the diagnostic tool. It can also be dynamically decrypted with low memory usage and low memory pressure on ECU flashing.

[0005] Other features and advantages of this application will become apparent from the following detailed description, or may be learned in part from practice of this application.

[0006] According to a first aspect of this application, an ECU upgrade package processing method is provided, applied to a diagnostic instrument, comprising: Step S1: Download the ECU upgrade package from the cloud server to the local database; Step S2: Encrypt the ECU upgrade package downloaded to the local database in blocks to obtain several data blocks and the encryption information corresponding to each data block; Step S3: Enter the ECU flashing task, dynamically locate the corresponding data block according to the offset requested by the ECU, decrypt the data block based on the encrypted information, and send the decrypted data block to the ECU. Step S4: Repeat step S3 until all data blocks are sent to the ECU.

[0007] In some embodiments of this application, based on the foregoing scheme, step S1 includes: Check for any incomplete download tasks; If some data from the ECU upgrade package exists and has been downloaded, the system will automatically query the number of bytes downloaded, obtain the interruption position, and send a resume request with a Range header to the cloud server to continue downloading the remaining data from the ECU upgrade package to the local database from the interruption position. If the data does not exist, the system will download the ECU upgrade package from the cloud server to the local database again. Once the ECU upgrade package is downloaded, a success marker file will be generated.

[0008] In some embodiments of this application, based on the foregoing scheme, the ECU upgrade package includes several blocks. The step of sending a resume request carrying a Range header to the cloud server according to the interruption location, and continuing to download the remaining data in the ECU upgrade package to the local database from the interruption location, includes: Based on the interruption location, obtain the number of bytes downloaded and the block status corresponding to the number of bytes downloaded. The block status corresponding to the number of bytes downloaded includes the total file size and the download task ID, block index, and block check value corresponding to the downloaded block. Based on the number of downloaded bytes and the corresponding block status, obtain the number of undownloaded bytes and the corresponding block status. The block status corresponding to the number of undownloaded bytes includes the total file size and the download task ID, block index, and block check value corresponding to the undownloaded block. Based on the download task ID, block index, and block checksum corresponding to the undownloaded block, continue downloading the remaining data in the ECU upgrade package to the local database.

[0009] In some embodiments of this application, based on the foregoing scheme, step S2 includes: Initiate a pre-flash handshake negotiation with the ECU to obtain the maximum block parameter, which is the maximum number of data bytes that the ECU can receive in a single flash. Using the maximum block parameter as the encryption block granularity, the ECU upgrade package is divided into several data blocks; Each of the data blocks is encrypted independently; Generate data information for each data block, including data block number, offset, number of data bytes, unique initialization vector, and index file self-check value; Add the data information and total number of data blocks for each data block to the success tag file.

[0010] In some embodiments of this application, based on the foregoing scheme, the AES-256-CBC algorithm is used to independently encrypt each of the data blocks.

[0011] In some embodiments of this application, based on the foregoing scheme, the maximum block parameter is the minimum of the ECU's hardware buffer size and the transport layer protocol stack.

[0012] In some embodiments of this application, based on the foregoing scheme, the process before entering the ECU flashing task includes: Check if the success tag file exists; If it does not exist, it is determined that the ECU upgrade package download is incomplete or corrupted, and a prompt will be made to download the ECU upgrade package again; If it exists, load the success flag file. When the total number of data blocks and the data information of each data block are verified, proceed to the ECU flashing task.

[0013] According to a second aspect of this application, an ECU upgrade package processing system is provided, comprising: The download module is used to download ECU upgrade packages from the cloud server to the local database; The encryption module is used to encrypt the ECU upgrade package downloaded to the local database in blocks, and obtain several data blocks and the encryption information corresponding to each data block; The decryption module is used to enter the ECU flashing task, dynamically locate the corresponding data block according to the offset requested by the ECU, decrypt the data block based on the encrypted information, and send the decrypted data block to the ECU. The transmission module is used to repeatedly decrypt the module until all data blocks are sent to the ECU.

[0014] According to a third aspect of this application, a computer-readable storage medium is provided that stores a computer program thereon, the computer program including executable instructions that, when executed by a processor, implement the method described above.

[0015] According to a fourth aspect of this application, an electronic device is provided, comprising: One or more processors; A memory for storing executable instructions of the processor, which, when executed by the one or more processors, cause the one or more processors to implement the method described above.

[0016] The beneficial effects of this application are as follows: (1) The ECU upgrade package processing method and system provided in this application set up a breakpoint resume download mechanism based on block status recording. By recording the number of downloaded bytes and block status, it supports continuing the download from the breakpoint after network interruption. The Range request header is used to realize breakpoint resume, avoiding repeated transmission of downloaded data and improving download efficiency.

[0017] (2) The ECU upgrade package processing method and system provided in this application perform independent encryption on the maximum block parameters of the ECU upgrade package. Each data block uses a unique initialization vector derived from the success tag file to ensure that the same data generates different ciphertext in different data blocks, thereby enhancing security. The ECU upgrade package (original plaintext file) is deleted immediately after encryption, achieving secure storage without data being written to disk. The design of independent storage of encrypted blocks allows each block to be managed and accessed independently.

[0018] (3) The ECU upgrade package processing method and system provided in this application establishes a success marker file system to record the offset, number of data bytes, unique initialization vector, and index file self-check value of each data block. During flashing, the target data block is quickly located through the success marker file, supporting precise random access and segmented decryption, providing a data foundation for dynamic decryption flashing. The success marker file also serves as the basis for verifying the integrity of the ECU upgrade package, ensuring data accuracy through multi-dimensional verification.

[0019] (4) The ECU upgrade package processing method and system provided in this application are designed with a dynamic decryption engine. The engine calculates the data block in real time based on the offset requested by the ECU, reads and decrypts the data block, and extracts only the required byte range to return to the flashing controller. This method realizes on-demand decryption and flashing while decrypting, and the memory usage is only the size of a single data block, which completely solves the memory bottleneck of flashing large-capacity ECU upgrade packages. After the ECU upgrade package is downloaded in its entirety, it is stored in the form of data blocks. During flashing, it is not necessary to decrypt the entire package. Only the blocks that are currently needed are decrypted and sent to the ECU immediately after decryption. No complete plaintext data is retained in memory.

[0020] (5) The ECU upgrade package processing method and system provided in this application construct a complete collaborative process of "resumable download → block encrypted storage → index positioning → dynamic decryption → real-time flashing", with each link closely connected. The ECU upgrade package is persistently stored in the form of encrypted data blocks, and is dynamically decrypted as needed during flashing, realizing the unity of storage security and execution efficiency, and significantly improving the diagnostic tool's ability to flash large-capacity ECUs.

[0021] It should be understood that the above general description and the following detailed description are merely exemplary and explanatory, and do not limit this application. Attached Figure Description

[0022] The accompanying drawings, which are included to provide a further understanding of the invention and form part of this application, illustrate exemplary embodiments of the invention and are intended to explain the invention, but do not constitute an undue limitation thereof. In the drawings: Figure 1 This is a flowchart of an ECU upgrade package processing method according to the present invention; Figure 2 This is a schematic diagram of an ECU upgrade package processing system according to the present invention; Figure 3 This is a schematic diagram of an electronic device according to the present invention. Detailed Implementation

[0023] To make the objectives, features, and advantages of this invention more apparent and understandable, the technical solutions of the embodiments of this invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the embodiments described below are only some embodiments of this invention, and not all embodiments. Based on the embodiments of this invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this invention.

[0024] It should be understood that the terms "comprising" and other similar expressions in the specification, claims, and accompanying drawings of this invention are intended to cover a non-exclusive inclusion, such as a process, method, system, or apparatus that includes a series of steps or units and is not limited to the listed steps or units. Furthermore, "first" and "second" are used to distinguish different objects and are not intended to describe a specific order.

[0025] According to the first aspect of this application, Figure 1 As shown, this embodiment provides an ECU upgrade package processing method, applied to a diagnostic instrument, including: Step S1: Download the ECU upgrade package from the cloud server to the local database.

[0026] In some embodiments of this example, downloading the ECU upgrade package from the cloud server to the local database, step S1 includes: Check for any incomplete download tasks; If some data from the ECU upgrade package exists and has been downloaded, the system will automatically query the number of bytes downloaded, obtain the interruption position, and send a resume request with a Range header to the cloud server to continue downloading the remaining data from the ECU upgrade package to the local database from the interruption position. If the data does not exist, the system will download the ECU upgrade package from the cloud server to the local database again. Once the ECU upgrade package is downloaded, a success marker file will be generated.

[0027] In related technologies, interrupted downloads of ECU upgrade packages require retransmission. Traditional ECU upgrade package downloads do not support resuming interrupted downloads. When the network is interrupted or the diagnostic tool restarts abnormally, all downloaded data is lost, requiring a complete re-download of the upgrade package, resulting in a waste of both time and bandwidth. This problem is particularly prominent in repair shops with poor network conditions. This embodiment provides an ECU upgrade package processing method that enables resuming interrupted downloads when incomplete download tasks are detected.

[0028] In this embodiment, the Range header is a range request header, used to remind the diagnostic tool to continue downloading the remaining data in the ECU upgrade package to the local database from the interrupted position.

[0029] In this embodiment, the ECU upgrade package is divided into several blocks, and these blocks are downloaded sequentially from the cloud server to the local database. When downloading each block, as shown in Table 1, the following information is obtained: Download Task ID, number of bytes downloaded, total file size, block index, and block checksum. The Download Task ID uniquely identifies each download task, the number of bytes downloaded records the amount of data that has been downloaded, the total file size is the complete size of the ECU upgrade package, the block index is the number of the downloaded block, and the block checksum is the hash checksum of each block, obtained using a hash algorithm (MD5 or SHA256).

[0030] Table 1. Core Elements of Resumable Downloads

[0031] Specifically, when a user selects to download an ECU upgrade package, the diagnostic tool first checks its local database for any incomplete download tasks. If such tasks exist and some data has already been downloaded, the download resumes from the recorded interruption point; otherwise, a completely new download begins. During the download process, the diagnostic tool records the number of bytes downloaded and the corresponding block status in real time, persistently storing this information in the local database. The block status corresponding to the number of downloaded bytes includes the total file size and key information such as the download task ID, block index, and block checksum of the downloaded block.

[0032] When the network is interrupted or the diagnostic tool restarts abnormally, upon restarting, the diagnostic tool automatically queries the local system for incomplete download tasks. Based on the recorded number of bytes downloaded and the corresponding chunk status, it sends a resume request with a Range header to the cloud server, requesting only the undownloaded portion of the data. It retrieves the number of undownloaded bytes and the corresponding chunk status, which includes the total file size and the download task ID, chunk index, and chunk checksum for the undownloaded chunk. Based on the download task ID, chunk index, and checksum for the undownloaded chunk, it continues downloading the remaining data from the ECU upgrade package to the local database. The cloud server returns the remaining data based on the Range header, and the diagnostic tool writes it to the local database in append mode, continuously updating the download progress until the complete upgrade package download is complete. After downloading, the system generates a success flag file to indicate that the ECU upgrade package has been completely downloaded.

[0033] Step S2: Encrypt the ECU upgrade package downloaded to the local database in blocks to obtain several data blocks and the encryption information corresponding to each data block.

[0034] In related technologies, ECU upgrade packages are stored in plaintext on the diagnostic tool's local disk. If the device is lost or illegally obtained, the firmware code in the upgrade package can be easily reverse-engineered, revealing the vehicle's core control algorithms and posing a serious security risk. In this embodiment, encryption effectively improves the information security of the ECU.

[0035] In some embodiments of this example, step S2 includes: Initiate a pre-flash handshake negotiation with the ECU to obtain the maximum block parameter, which is the maximum number of data bytes that the ECU can receive in a single flash. The ECU upgrade package is divided into several data blocks using the maximum block parameter as the encryption block granularity. Each data block is encrypted independently; Generate data information for each data block, including data block number, offset, number of data bytes, unique initialization vector, and index file self-check value; Add the data information and total number of data blocks for each data block to the success tag file.

[0036] Specifically, to further improve flashing efficiency and achieve optimal matching between encryption block granularity and transmission granularity, this embodiment introduces an adaptive encryption block granularity negotiation mechanism based on the fixed block scheme. This mechanism shifts the decision-making time for the encryption block granularity size to after communication with the ECU, enabling the encryption strategy to perceive and adapt to the actual transmission capacity of the ECU.

[0037] Before performing the ECU upgrade package encryption process, the diagnostic tool assembles a UDS 34 service (request download) message based on the flashing task and initiates a pre-flash handshake negotiation with the ECU. Upon receiving the UDS 34 service request, the ECU performs receive preparation according to its own memory management strategy and communication stack configuration and returns a positive response message. The data field of the positive response message contains a key parameter: maxNumberOfBlockLength (maximum block length). The maximum block length represents the maximum number of data bytes the ECU can receive in a single UDS 36 service (transfer data service). The maximum block length is determined by factors such as the ECU's hardware receive buffer size and transport layer protocol stack configuration.

[0038] The diagnostic tool extracts the parameter value of maxNumberOfBlockLength (maximum block length) from the positive response message. In this embodiment, the diagnostic tool directly uses the maximum block length as the granularity of encryption blocks. In this way, the size of the data block is strictly consistent with the maximum single-pass reception capability of the ECU, laying the foundation for a precise 1:1 mapping between encryption and transmission in the subsequent flashing stage.

[0039] Each data block is independently encrypted using the AES-256-CBC algorithm, with the encryption key generated from hardware information. The encrypted data blocks are written to separate data block files, with the filename containing the data block sequence number. After encryption, a success marker file is generated as a marker of the upgrade package's integrity and availability. This success marker file contains basic information about the ECU upgrade package, the total number of data blocks, and the data information for each data block, including the data block sequence number, offset, number of data bytes, unique initialization vector, and the index file's own checksum.

[0040] In this embodiment, the success tag file is the core tag for the integrity and availability of the upgrade package. Its content is organized in JSON format and includes the following information: ECU upgrade package version identifier, unique package identifier, ECU upgrade package data volume, total number of data blocks, encryption algorithm type, key derivation method, overall hash check value, and data information for each data block. The data information includes data block sequence number, offset, number of data bytes, unique initialization vector, creation timestamp, and index file self-check value, etc.

[0041] Step S3: Enter the ECU flashing task, dynamically locate the corresponding data block according to the offset requested by the ECU, decrypt the data block based on the encrypted information, and send the decrypted data block to the ECU.

[0042] In existing technologies, flashing ECU upgrade packages typically requires downloading the entire package before flashing can begin. Furthermore, the entire upgrade package must be decrypted during flashing, making on-demand decryption impossible. Memory usage is directly proportional to the upgrade package size, limiting the diagnostic tool's ability to flash large-capacity ECUs. For upgrade packages several gigabytes in size, the diagnostic tool's memory resources struggle to handle them, easily leading to flashing failures or system crashes. The encryption / decryption method in this embodiment effectively reduces the memory usage for decryption, enabling on-demand decryption.

[0043] In some embodiments of this example, before entering the ECU flashing task, the following steps are included: Check if the success tag file exists; If it does not exist, it is determined that the ECU upgrade package download was incomplete or corrupted, and you will be prompted to download the ECU upgrade package again; If it exists, load the success flag file. When the total number of data blocks and the data information of each data block are verified, proceed to the ECU flashing task.

[0044] Specifically, when the diagnostic tool is ready to perform the flashing operation, it checks whether a success marker file exists. If it does not exist, it determines that the ECU upgrade package download is incomplete or corrupted, and prompts the user to download it again. If it exists, it loads the success marker file and verifies whether the overall hash checksum is complete, whether the number of data blocks matches, and whether the ECU upgrade package data volume is correct. Only after all verifications pass can the flashing process proceed. This mechanism ensures that the upgrade package data used during flashing is complete and error-free.

[0045] This embodiment employs dynamic decryption technology. During flashing, the corresponding encrypted blocks are located and decrypted in real time based on the byte offset requested by the ECU, enabling on-demand decryption and flashing simultaneously, significantly reducing memory usage. After the complete ECU upgrade package is downloaded, it is stored on the disk in encrypted blocks. During flashing, the data block corresponding to the offset requested by the ECU is dynamically located and decrypted. Only the data block that needs to be flashed is decrypted into memory, without needing to decrypt the entire ECU upgrade package. The decrypted data is directly sent to the ECU, and no complete plaintext is retained in memory.

[0046] This embodiment integrates the above mechanism into a complete flashing process. The user selects the ECU upgrade package to be flashed, and the diagnostic tool activates the resume download function to check if there are any incomplete download tasks locally. If so, the download continues from the breakpoint; otherwise, a completely new download begins. Progress is recorded in real time during the download process to ensure recovery after network interruption.

[0047] After the download is complete, the diagnostic tool automatically performs block encryption on the ECU upgrade package, dividing the original upgrade package into the maximum number of data bytes that the ECU can receive at one time. Each data block is encrypted independently and stored as a separate block file. After encryption, the original plaintext file (ECU upgrade package) is deleted to ensure that only encrypted data is stored on the disk.

[0048] When a user performs a flashing operation, the diagnostic tool loads a success marker file for integrity verification. Once verification is successful, the flashing process begins. During flashing, the diagnostic tool dynamically locates and decrypts the corresponding data blocks based on the offset requested by the ECU. Only the currently needed blocks are decrypted and stored in memory. After extracting the required data, it is immediately sent to the ECU, and then the memory is released. This process is repeated until all data has been flashed. Through index management of the encrypted block data, upgrade data within a specified byte range can be precisely located and decrypted, achieving the goal of supporting segmented flashing and random access.

[0049] In some implementations of this example, the maximum block length parameter is the minimum of the ECU's hardware buffer size and the transport layer protocol stack size. For example, suppose the ECU's hardware receive buffer is 4KB, but the underlying CANFD protocol stack configures a single transmission unit of 2KB to reduce bus load and latency. Then, the ECU will ultimately return a maxNumberOfBlockLength of 2KB. This maxNumberOfBlockLength is both safe enough to fit into a 4KB buffer and meets the protocol stack's most efficient transmission limit.

[0050] Step S4: Repeat step S3 until all data blocks are sent to the ECU.

[0051] According to the second aspect of this application, such as Figure 2 As shown, this embodiment provides an ECU upgrade package processing system, including: The download module is used to download ECU upgrade packages from the cloud server to the local database; The encryption module is used to encrypt the ECU upgrade package downloaded to the local database in blocks, and obtain several data blocks and the encryption information corresponding to each data block; The decryption module is used to respond to the ECU flashing task, dynamically locate the corresponding data block according to the offset requested by the ECU, decrypt the data block based on the encrypted information, and send the decrypted data block to the ECU. The transmission module is used to repeatedly decrypt the module until all data blocks are sent to the ECU.

[0052] Specifically, this embodiment corresponds one-to-one with the above method embodiments. The functions of each module have been described in detail in the corresponding method embodiments, so they will not be repeated here.

[0053] According to a third aspect of this application, this embodiment provides a computer-readable storage medium having a computer program stored thereon, the computer program including executable instructions that, when executed by a processor, implement the method described above.

[0054] The present invention can implement all or part of the processes in the above methods, or it can be accomplished by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. The computer-readable medium can include: any entity or system capable of carrying computer program code, recording media, USB flash drives, portable hard drives, magnetic disks, optical disks, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media, etc. It should be noted that the content included in the computer-readable medium can be appropriately added or removed according to the requirements of legislation and patent practice in the jurisdiction. For example, in some jurisdictions, according to legislation and patent practice, the computer-readable medium does not include electrical carrier signals and telecommunication signals.

[0055] According to the fourth aspect of this application, such as Figure 3 As shown, an electronic device is provided, comprising: One or more processors; Memory is used to store executable instructions for the processor, which, when executed by one or more processors, cause one or more processors to implement the methods described above.

[0056] Electronic devices are manifested in the form of general-purpose computing devices. Components of an electronic device may include, but are not limited to: at least one processor, at least one memory, and a bus connecting different system components (including memory and processor).

[0057] The processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor can be a microprocessor or any conventional processor. The processor is the control center of a computer system, connecting all parts of the computer system through various interfaces and lines.

[0058] Memory can be used to store computer programs and / or modules. The processor implements various functions of the computer system by running or executing the computer programs and / or modules stored in the memory, and by accessing data stored in the memory. Memory can mainly include a program storage area and a data storage area. The program storage area can store the operating system and at least one application program required for a function (e.g., sound playback, image playback, etc.); the data storage area can store data created based on the use of the mobile phone (e.g., audio data, video data, etc.). Furthermore, memory can include high-speed random access memory, and can also include non-volatile memory, such as hard disks, RAM, plug-in hard disks, SmartMedia Cards (SMC), Secure Digital (SD) cards, Flash Cards, at least one disk storage device, flash memory device, or other volatile solid-state storage devices.

[0059] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, servers, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage and memory) containing computer-usable program code.

[0060] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), servers, and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A system that specifies functions in one or more boxes.

[0061] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including an instruction set implemented in a process. Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0062] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

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

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

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

Claims

1. A method for processing ECU upgrade packages, applied to a diagnostic instrument, characterized in that, include: Step S1: Download the ECU upgrade package from the cloud server to the local database; Step S2: Encrypt the ECU upgrade package downloaded to the local database in blocks to obtain several data blocks and the encryption information corresponding to each data block; Step S3: Enter the ECU flashing task, dynamically locate the corresponding data block according to the offset requested by the ECU, decrypt the data block based on the encrypted information, and send the decrypted data block to the ECU. Step S4: Repeat step S3 until all data blocks are sent to the ECU.

2. The method according to claim 1, characterized in that, Step S1 includes: Check for any incomplete download tasks; If some data from the ECU upgrade package exists and has been downloaded, the system will automatically query the number of bytes downloaded, obtain the interruption position, and send a resume request with a Range header to the cloud server to continue downloading the remaining data from the ECU upgrade package to the local database from the interruption position. If the data does not exist, the system will download the ECU upgrade package from the cloud server to the local database again. Once the ECU upgrade package is downloaded, a success marker file will be generated.

3. The method according to claim 2, characterized in that, The ECU upgrade package comprises several blocks. The step of sending a resume request carrying a Range header to the cloud server based on the interruption location, and continuing to download the remaining data in the ECU upgrade package to the local database from the interruption location, includes: Based on the interruption location, obtain the number of bytes downloaded and the block status corresponding to the number of bytes downloaded. The block status corresponding to the number of bytes downloaded includes the total file size and the download task ID, block index, and block check value corresponding to the downloaded block. Based on the number of downloaded bytes and the corresponding block status, obtain the number of undownloaded bytes and the corresponding block status. The block status corresponding to the number of undownloaded bytes includes the total file size and the download task ID, block index, and block check value corresponding to the undownloaded block. Based on the download task ID, block index, and block checksum corresponding to the undownloaded block, continue downloading the remaining data in the ECU upgrade package to the local database.

4. The method according to claim 1, characterized in that, Step S2 includes: Initiate a pre-flash handshake negotiation with the ECU to obtain the maximum block parameter, which is the maximum number of data bytes that the ECU can receive in a single flash. Using the maximum block parameter as the encryption block granularity, the ECU upgrade package is divided into several data blocks; Each of the data blocks is encrypted independently; Generate data information for each data block, including data block number, offset, number of data bytes, unique initialization vector, and index file self-check value; Add the data information and total number of data blocks for each data block to the success tag file.

5. The method according to claim 4, characterized in that: Each data block is encrypted independently using the AES-256-CBC algorithm.

6. The method according to claim 4, characterized in that: The maximum block parameter is the minimum of the ECU's hardware buffer size and the transport layer protocol stack size.

7. The method according to claim 1, characterized in that, Before entering the ECU flashing task, the following are included: Check if the success tag file exists; If it does not exist, it is determined that the ECU upgrade package download is incomplete or corrupted, and a prompt will be made to download the ECU upgrade package again; If it exists, load the success flag file. When the total number of data blocks and the data information of each data block are verified, proceed to the ECU flashing task.

8. An ECU upgrade package processing system, applied to a diagnostic instrument, characterized in that, include: The download module is used to download ECU upgrade packages from the cloud server to the local database; The encryption module is used to encrypt the ECU upgrade package downloaded to the local database in blocks, and obtain several data blocks and the encryption information corresponding to each data block; The decryption module is used to enter the ECU flashing task, dynamically locate the corresponding data block according to the offset requested by the ECU, decrypt the data block based on the encrypted information, and send the decrypted data block to the ECU. The transmission module is used to repeatedly decrypt the module until all data blocks are sent to the ECU.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that, The computer program includes executable instructions that, when executed by a processor, implement the method of any one of claims 1-7.

10. An electronic device, characterized in that, include: One or more processors; A memory for storing executable instructions of the processor, which, when executed by the one or more processors, cause the one or more processors to perform the method according to any one of claims 1-7.

Images