Backup method, backup device, computer readable storage medium and vehicle of OTA

By checking the consistency of the ECU system program during the OTA process and pausing the backup process while the download process is running, the problem of duplicate backups is solved, thus improving the stability and efficiency of the OTA process.

CN116594806BActive Publication Date: 2026-04-24WEICHAI POWER CO LTD +1
View PDF 2 Cites 0 Cited by

Patent Information

Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
WEICHAI POWER CO LTD
Filing Date
2023-03-24
Publication Date
2026-04-24

AI Technical Summary

Technical Problem

In existing technologies, the problem of duplicate backups caused by backing up before downloading during OTA backup affects the stability and efficiency of the OTA process.

Method used

By determining whether the first system program and the second system program of the ECU are consistent, if they are inconsistent, they are backed up to random access memory. The backup process is paused during the download process and resumed after the download is completed. The receiving array is shared to improve the efficiency of memory resource utilization.

Benefits of technology

It avoids duplicate backups, ensures the stability and efficiency of the OTA process, improves the utilization efficiency of memory resources, and solves the problem of duplicate backups caused by backing up before downloading in existing technologies.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN116594806B_ABST
    Figure CN116594806B_ABST
Patent Text Reader

Abstract

The application provides an OTA backup method, a backup device, a computer readable storage medium and a vehicle. The method comprises the following steps: determining whether a first system program and a second system program are consistent; in the case that the first system program and the second system program are inconsistent, at least calling a receiving array to execute a backup process, the backup process being used for temporarily storing the first system program in a random access memory and then backing up the first system program to a second storage partition; in the case that the backup process is in a running state, determining whether there is a download process in the process executed by the receiving array, the download process being used for downloading a third system program and updating the second system program; in the case that the download process exists and the download process is in the running state, suspending the backup process until the receiving array finishes executing the download process, and calling the receiving array to continue executing the backup process. The flexible backup method solves the problem of repeated backup caused by prior art backup before downloading.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This invention relates to the field of OTA backup, and more specifically, to an OTA backup method, backup device, computer-readable storage medium, and vehicle. Background Technology

[0002] Existing OTA (Over-The-Air) technology typically uses ECUs with sufficient memory, allowing downloads and backups to use their own data receiving arrays without interference. Data downloads can only proceed after a backup is completed. ECUs with external flash memory divide this memory into two areas: Flash and Flash_copy. One area stores programs and data downloaded from the cloud platform, while the other is used to back up the currently running EMS (Electronic Management System) area of ​​the ECU. Specific processes and methods are as follows... Figure 1 As shown. Summary of the Invention

[0003] The main objective of this application is to provide an OTA backup method, backup device, computer-readable storage medium, and vehicle, so as to at least solve the problem of duplicate backups caused by backing up before downloading in the prior art.

[0004] To achieve the above objectives, according to one aspect of this application, an OTA backup method is provided, comprising: determining whether a first system program and a second system program are consistent, wherein the first system program is a system program running on an EMS, and the second system program is a system program stored in a first storage partition, the first storage partition being a storage partition in the external flash memory of an ECU; if the first system program and the second system program are inconsistent, at least a receiving array is invoked to execute a backup process, the receiving array being used to store data in random access memory, the backup process being used to temporarily store the first system program in random access memory and then back it up to the second storage partition, the second storage partition being another storage partition in the external flash memory of the ECU; if the backup process is running, determining whether a download process exists in the process executed by the receiving array, the download process being used to download a third system program and update the second system program in the first storage partition through the third system program, the third system program being a system program issued by a cloud platform to the ECU; if the download process exists in the process executed by the receiving array and the download process is running, pausing the backup process until the receiving array finishes executing the download process, and then invoking the receiving array to continue executing the backup process.

[0005] Optionally, determining whether the first system program and the second system program are consistent includes: obtaining the checksum of the first system program, obtaining the checksum of the second system program corresponding to the first system program, wherein the checksum is used to identify the system program version, and the checksum includes at least a first checksum and a second checksum, wherein the first checksum is the checksum contained in the first system program, and the second checksum is the checksum contained in the second system program; if the checksum of the first system program and the checksum of the second system program corresponding to the first system program are consistent, the first system program and the second system program are determined to be consistent; if the checksum of the first system program and the checksum of the corresponding second system program are inconsistent, the first system program and the second system program are determined to be inconsistent.

[0006] Optionally, before determining whether a download process exists in the process executed by the receiving array, the method further includes: obtaining a first checksum and a third checksum, wherein the third checksum is a checksum contained in the third system program; obtaining the name of a third storage partition and the name of a fourth storage partition, wherein the third storage partition is a storage partition in the built-in flash memory of the ECU requested by the third system program, and the fourth storage partition is a storage partition in the built-in flash memory of the ECU occupied by the first system program; and, if the first checksum and the third checksum are inconsistent and the name of the third storage partition is consistent with the name of the fourth storage partition, invoking the receiving array to execute the download process.

[0007] Optionally, after the receiving array completes the download process, the method further includes: detecting whether the random access memory (RAM) has an OTA flash status variable, wherein the OTA flash status variable is generated by the RAM when the flash operation performed by the download process is normal, and the flash operation is used to update the first system program; if the OTA flash status variable exists, determining that the flash operation performed by the download process is normal, calling the Bootloader to obtain the third system program from the first storage partition, and updating the first system program according to the third system program, wherein the Bootloader is a bootloader that updates the first system program.

[0008] Optionally, after detecting whether the random access memory has an OTA flashing status variable, the method further includes: if a predetermined condition is met or if the OTA flashing status variable is detected to be absent, calling the Bootloader to obtain a fourth system program from the second storage partition, and updating the third system program according to the fourth system program, wherein the fourth system program is obtained by the backup process from the first system program, and the predetermined condition is that an abnormal power outage occurs during the flashing process of the random access memory or the third system program malfunctions.

[0009] Optionally, calling the receiving array to continue executing the backup process includes: obtaining the checksum of the first system program and the checksum of the corresponding second system program; if the checksum of the first system program and the checksum of the corresponding second system program are inconsistent, calling the receiving array to continue executing the backup process.

[0010] Optionally, after the receiving array completes the download process, the method further includes: determining whether there is an OTA flashing process startup request; if there is no startup request, calling the receiving array to continue executing the backup process; if there is a startup request and the checksum of the first system program is inconsistent with the checksum of the corresponding second system program, using the Bootloader to continue executing the backup process.

[0011] According to another aspect of this application, an OTA backup device is provided, comprising: a first comparison unit, configured to determine whether a first system program and a second system program are consistent, wherein the first system program is a system program running on an EMS, and the second system program is a system program stored in a first storage partition, wherein the first storage partition is a storage partition in an external flash memory of an ECU; and a first processing unit, configured to, in the event that the first system program and the second system program are inconsistent, at least invoke a receiving array to execute a backup process, wherein the receiving array is configured to store data in a random access memory, and the backup process is configured to temporarily store the first system program in the random access memory and then back it up to the second storage partition, wherein the second system program is a system program stored in a random access memory. The storage partition is another storage partition in the external flash memory of the ECU; the first judgment unit is used to determine whether there is a download process in the process executed by the receiving array when the backup process is running, the download process is used to download a third system program and update the second system program in the first storage partition through the third system program, the third system program is a system program sent by the cloud platform to the ECU; the second processing unit, when there is a download process in the process executed by the receiving array and the download process is running, pauses the backup process until the receiving array finishes executing the download process, and then calls the receiving array to continue executing the backup process.

[0012] According to another aspect of this application, a computer-readable storage medium is provided, the computer-readable storage medium including a stored program, wherein, when the program is executed, it controls the device on which the computer-readable storage medium is located to perform any of the methods described.

[0013] According to another aspect of this application, a vehicle is provided, comprising: an engine, one or more processors, a memory, and one or more programs, wherein the engine includes an ECU and an external flash memory, the ECU is equipped with an EMS and a bootloader, the external flash memory is communicatively connected to the ECU, the one or more programs are stored in the memory and configured to be executed by the one or more processors, and the one or more programs include methods for performing any one of the methods described.

[0014] Applying the technical solution of this application, firstly, it is determined whether the first system program and the second system program are consistent. The first system program is the system program running on the EMS, and the second system program is the system program stored in the first storage partition, which is a storage partition in the external flash memory of the ECU. Then, if the first system program and the second system program are inconsistent, at least the receiving array is invoked to execute the backup process. The receiving array is used to store data in random access memory, and the backup process is used to temporarily store the first system program in random access memory and then back it up to the second storage partition, which is another storage partition in the external flash memory of the ECU. Afterward, while the backup process is running, it is determined whether there is a download process in the process executed by the receiving array. The download process is used to download a third system program and update the second system program in the first storage partition through the third system program. The third system program is the system program sent by the cloud platform to the ECU. Finally, if there is a download process in the process executed by the receiving array and the download process is running, the backup process is paused until the receiving array finishes executing the download process, and then the receiving array is invoked to continue executing the backup process. This method uses a single receiving array for backup and download to improve memory resource utilization efficiency. To avoid conflicts between backup and download, a download-first solution is proposed, and backup continues during idle time after download is completed. This flexible backup scheme solves the problem of duplicate backups caused by backing up before downloading in existing technologies, and also ensures the stability of the OTA process. Attached Figure Description

[0015] Figure 1 The diagram illustrates an OTA download, backup, flashing, and rollback process based on the background technology.

[0016] Figure 2 A hardware structure block diagram of a mobile terminal performing an OTA backup method according to an embodiment of this application is shown;

[0017] Figure 3 A flowchart illustrating an OTA backup method according to an embodiment of this application is shown.

[0018] Figure 4 A flowchart illustrating the download, backup, flashing, and rollback process of an OTA (Over-The-Air) device according to an embodiment of this application is shown.

[0019] Figure 5 A flowchart illustrating an OTA backup method according to another embodiment of this application is shown.

[0020] Figure 6A structural block diagram of an OTA backup device provided according to an embodiment of this application is shown. Detailed Implementation

[0021] It should be noted that, unless otherwise specified, the embodiments and features described in this application can be combined with each other. This application will now be described in detail with reference to the accompanying drawings and embodiments.

[0022] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort should fall within the scope of protection of the present application.

[0023] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate for the embodiments of this application described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0024] For ease of description, the following explains some of the nouns or terms used in the embodiments of this application:

[0025] ECU: Electronic Control Unit;

[0026] EMS: Engine Management System, used to control the engine's operating status;

[0027] OTA (Over-The-Air) technology downloads programs and data from a cloud platform via a wireless communication module to update the programs and data in the ECU (Electronic Control Unit). This primarily refers to remote flashing of the ECU, which mainly involves four steps: backup, download, flashing, and rollback.

[0028] Bootloader: A bootloader used in embedded operating systems, running before the operating system kernel. It initializes hardware devices and establishes a memory space mapping, bringing the system's hardware and software environment to a suitable state. This facilitates the final call to the operating system kernel to prepare the correct environment and complete the system startup task. This primarily refers to the bootloader's loading mode, where the bootloader loads the operating system from a solid-state storage device on the target host into RAM; and the download mode, where the bootloader on the target host downloads the kernel image and root file system image from the development host to RAM via serial port or network communication, and then writes the downloaded data to the target host's solid-state storage.

[0029] As described in the background section, in the prior art, downloading can only be performed after backup is complete. To solve the problem of duplicate backups caused by backing up first and then downloading in the prior art, embodiments of this application provide an OTA backup method, backup device, computer-readable storage medium, and vehicle.

[0030] The technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present invention.

[0031] The methods and embodiments provided in this application can be executed on a mobile terminal, computer terminal, or similar computing device. Taking running on a mobile terminal as an example, Figure 2 This is a hardware structure block diagram of a mobile terminal for an OTA backup method according to an embodiment of the present invention. Figure 2 As shown, a mobile terminal may include one or more ( Figure 2 Only one is shown in the diagram. A processor 102 (which may include, but is not limited to, a microprocessor MCU or a programmable logic device FPGA, etc.) and a memory 104 for storing data are also shown. The mobile terminal may further include a transmission device 106 for communication functions and an input / output device 108. Those skilled in the art will understand that... Figure 2 The structure shown is for illustrative purposes only and does not limit the structure of the mobile terminal described above. For example, the mobile terminal may also include components that are more... Figure 2 The more or fewer components shown, or having the same Figure 2 The different configurations shown.

[0032] The memory 104 can be used to store computer programs, such as application software programs and modules, like the computer program corresponding to the device information display method in this embodiment of the invention. The processor 102 executes various functional applications and data processing by running the computer program stored in the memory 104, thereby implementing the above-described method. The memory 104 may include high-speed random access memory and non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 104 may further include memory remotely located relative to the processor 102, and these remote memories can be connected to the mobile terminal via a network. Examples of the aforementioned networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof. The transmission device 106 is used to receive or send data via a network. Specific examples of the aforementioned networks may include wireless networks provided by the mobile terminal's communication provider. In one example, the transmission device 106 includes a network interface controller (NIC), which can be connected to other network devices via a base station to communicate with the Internet. In one example, the transmission device 106 may be a radio frequency (RF) module, which is used to communicate with the Internet wirelessly.

[0033] This embodiment provides a backup method for OTA running on a mobile terminal, computer terminal or similar computing device. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0034] Figure 3 This is a flowchart of an OTA backup method according to an embodiment of this application. Figure 3 As shown, the method includes the following steps:

[0035] Step S201: Determine whether the first system program and the second system program are consistent. The first system program is the system program running on the EMS, and the second system program is the system program stored in the first storage partition. The first storage partition is a storage partition in the external flash memory of the ECU.

[0036] Specifically, the aforementioned EMS refers to the engine management system of an automobile. The first system program is the software program stored in the EMS area of ​​the ECU's built-in Flash memory, used to enable the engine management system to control the engine. The second system program is the system program stored in the Flash area of ​​the ECU's external Flash memory; this Flash area is the first storage partition mentioned above. Figure 4 As shown, updating the system program in the EMS area requires comparing the first system program and the second system program to determine if their versions are consistent, that is, to determine if the system program running in the EMS is the latest version.

[0037] Step S202: In the case that the first system program and the second system program are inconsistent, at least the receiving array is called to execute the backup process. The receiving array is used to store data in random access memory. The backup process is used to temporarily store the first system program in random access memory and then back it up to the second storage partition. The second storage partition is another storage partition in the external flash memory of the ECU.

[0038] Specifically, such as Figure 4 As shown, if the first system program and the second system program are inconsistent, it can be determined that the first system program is not the latest version. In this case, the first system program needs to be updated. To avoid ECU malfunctions due to flashing during the update process, which would render the ECU unrepairable, the current first system program running in the EMS (Electronic Storage System), i.e., the old version, needs to be backed up for backup. The backup process requires calling the receive array to temporarily store the first system program in the random access memory (RAM), i.e., the common RAM in the ECU of this application. Then, the ECU stores the first system program from the common RAM into the Flash copy area in the ECU's external Flash memory. This Flash copy area is the second storage partition.

[0039] Step S203: When the backup process is running, determine whether there is a download process in the process executed by the above receiving array. The download process is used to download the third system program and update the second system program in the first storage partition through the third system program. The third system program is the system program sent by the cloud platform to the ECU.

[0040] Specifically, to improve memory resource utilization efficiency, the backup process and the download process in this application use the same receive array. Therefore, to prevent conflicts and data errors between the backup process and the download process, this application proposes a priority order for the download process. Figure 4As shown, during the backup process described above, it is necessary to determine whether the download process is present in the receiving array. The download process involves downloading the new version of the system program from the cloud platform to the Flash area of ​​the ECU's external Flash memory. This means temporarily storing the third system program in the common RAM, and then the ECU stores the third system program from the common RAM into the Flash area, overwriting the second system program.

[0041] Step S204: If the download process exists and is running in the process executed by the receiving array, pause the backup process until the receiving array finishes executing the download process, and then call the receiving array to continue executing the backup process.

[0042] Specifically, if it is determined that the download process is one of the processes running in the aforementioned receiving array, in order to prevent the backup process from conflicting with the download process and causing data errors, such as... Figure 4 As shown, the ongoing backup process is paused, and then resumed after the download process is completed, provided that the platform or customer does not immediately update the system programs running in EMS. This avoids duplicate backups of the already backed-up portion due to inconsistencies between the backed-up first system program and the overwritten second system program.

[0043] Applying the technical solution of this application, firstly, it is determined whether the first system program and the second system program are consistent. The first system program is the system program running on the EMS, and the second system program is the system program stored in the first storage partition, which is a storage partition in the external flash memory of the ECU. Then, if the first system program and the second system program are inconsistent, at least the receiving array is invoked to execute the backup process. The receiving array is used to store data in random access memory, and the backup process is used to temporarily store the first system program in random access memory and then back it up to the second storage partition, which is another storage partition in the external flash memory of the ECU. Afterward, while the backup process is running, it is determined whether there is a download process in the process executed by the receiving array. The download process is used to download a third system program and update the second system program in the first storage partition through the third system program. The third system program is the system program sent by the cloud platform to the ECU. Finally, if there is a download process in the process executed by the receiving array and the download process is running, the backup process is paused until the receiving array finishes executing the download process, and then the receiving array is invoked to continue executing the backup process. This method uses a single receiving array for backup and download to improve memory resource utilization efficiency. To avoid conflicts between backup and download, a download-first solution is proposed, and backup continues during idle time after download is completed. This flexible backup scheme solves the problem of duplicate backups caused by backing up before downloading in existing technologies, and also ensures the stability of the OTA process.

[0044] To determine whether to execute the backup process described above, in one optional implementation, step S201 includes:

[0045] Step S2021: Obtain the checksum of the first system program and the checksum of the second system program corresponding to the first system program. The checksum is used to identify the system program version. The checksum includes at least a first checksum and a second checksum. The first checksum is the checksum included in the first system program, and the second checksum is the checksum included in the second system program.

[0046] Specifically, the first system program is stored in the EMS area. Different functions of the first system program are stored in different secondary partitions within the EMS area, such as the program area, calibration area, and multiple EOL areas. The EOL area is the project termination area, used to terminate the process. Different partitions have different checksums, and the second system program also has a corresponding checksum. These checksums are used to distinguish system versions, functioning similarly to a version number.

[0047] Step S2022: If the checksum of the first system program is consistent with the checksum of the second system program corresponding to the first system program, it is determined that the first system program and the second system program are consistent; if the checksum of the first system program and the checksum of the second system program corresponding to the first system program are inconsistent, it is determined that the first system program and the second system program are inconsistent.

[0048] Specifically, since the first checksum used to identify the system version corresponds one-to-one with the second checksum, if the corresponding parts of the first checksum and the second checksum are the same, it means that the first system program and the second system program are in the same version; if the corresponding parts of the first checksum and the second checksum are not the same, it means that the first system program and the second system program are in different versions.

[0049] In order to determine whether to accept the new system issued by the cloud platform, in one optional implementation, before step S203, the method further includes:

[0050] Step S301: Obtain the first checksum and the third checksum, wherein the third checksum is the checksum contained in the third system program;

[0051] Specifically, such as Figure 4 As shown, after the system program is distributed on the cloud platform, it is necessary to first determine whether the version distributed by the cloud platform is a new version relative to the version running in the EMS. Therefore, it is necessary to obtain the checksum of the system program distributed by the cloud platform, i.e., the checksum of the third system program, and compare it with the checksum of the first system program to determine whether the versions of the third system program and the first system program are consistent.

[0052] Step S302: Obtain the name of the third storage partition and the name of the fourth storage partition. The third storage partition is the storage partition in the built-in flash memory of the ECU requested by the third system program, and the fourth storage partition is the storage partition in the built-in flash memory of the ECU occupied by the first system program.

[0053] Specifically, such as Figure 4 As shown, obtaining the name of the storage partition requested by the third system program is equivalent to obtaining the corresponding location of the EMS area occupied by the third system program when it runs in the EMS. Comparing the name of the third storage partition with the name of the fourth storage partition is equivalent to determining whether the address range occupied by the third system program and the first system program during runtime is consistent. Only if they are consistent can the third system program be adapted to the ECU. If they are inconsistent, it proves that the third system program cannot run smoothly in the ECU.

[0054] Step S303: If the first checksum is inconsistent with the third checksum and the name of the third storage partition is consistent with the name of the fourth storage partition, the receiving array is invoked to execute the download process.

[0055] Specifically, such as Figure 4 As shown, if the first checksum and the third checksum are inconsistent, and the name of the third storage partition is the same as the name of the fourth storage partition, it indicates that the third system program is a new system relative to the first system program, and that the third system program is compatible with the ECU. Therefore, at least the receiving array is invoked to complete the download process, and the third system program is stored in the third storage partition for later use.

[0056] To ensure the smooth progress of system program updates, in an optional implementation, after step S204, the method further includes:

[0057] Step S401: Detect whether the above random access memory has an OTA flashing status variable. The above OTA flashing status variable is generated when the flashing operation performed by the above download process is normal. The above flashing operation is used to update the above first system program.

[0058] Specifically, to prevent abnormal flashing operations from causing abnormal updates to the system program in the ECU, which could lead to ECU malfunction, such as... Figure 4 As shown, the above-mentioned OTA flashing status variable needs to be generated in the public RAM before the flashing operation is performed to indicate that the flashing operation is proceeding normally.

[0059] Step S402: If the above-mentioned OTA flashing status variable exists, it is determined that the flashing operation performed by the above-mentioned download process is normal. The Bootloader is called to obtain the above-mentioned third system program from the above-mentioned first storage partition, and the above-mentioned first system program is updated according to the above-mentioned third system program. The above-mentioned Bootloader is the bootloader program for updating the above-mentioned first system program.

[0060] Specifically, if the aforementioned OTA flashing status variable exists in the aforementioned public RAM, it indicates that the upcoming flashing operation is a normal operation. For example... Figure 4As shown, the flashing operation begins at this point. First, the Bootloader is invoked to load the third system program from the external Flash memory into RAM via network communication. Then, the third system program is written to the third storage partition, completing the update of the first system program. During this operation, the Bootloader program is in download mode, performing the function of downloading the kernel image and root file system image from the development host to RAM via serial port or network communication, and then writing the kernel image and root file system image to the solid-state storage media of the target host.

[0061] In response to the fault caused by the aforementioned third system program, in an optional implementation, after step S401, the method includes:

[0062] Step S501: If a predetermined condition is met or if it is detected that the above-mentioned OTA flashing status variable does not exist, the above-mentioned Bootloader is called to obtain the fourth system program from the above-mentioned second storage partition, and the above-mentioned third system program is updated according to the above-mentioned fourth system program. The above-mentioned fourth system program is obtained by the above-mentioned backup process from the above-mentioned first system program. The above-mentioned predetermined condition is that an abnormal power failure occurs during the flashing process of the above-mentioned random access memory or the above-mentioned third system program runs abnormally.

[0063] Specifically, such as Figure 4 As shown, if the OTA flashing status variable was not detected before the flashing operation was performed, or if a power outage or abnormal operation of the third system program occurred during the flashing process, i.e., the ECU malfunctioned due to a system program issue, a rollback operation is performed. This involves flashing the system program backed up to the Flash copy area (i.e., the fourth system data) to the EMS area. This restores the system in the ECU to its state before the update, resolving the aforementioned fault.

[0064] To avoid duplicate backups, in an optional implementation, step S204 includes:

[0065] Step S2041: Obtain the checksum of the first system program and obtain the checksum of the second system program corresponding to the first system program;

[0066] Specifically, in order to solve the problem of duplicate backups, this application implements the function of resuming interrupted downloads. To determine the breakpoint of the backup process, it is necessary to obtain the checksum of the first system program and compare it with the checksum of the second system program.

[0067] In step S2042, if the checksum of the first system program and the checksum of the second system program corresponding to the first system program are inconsistent, the backup process is continued by calling the receiving array.

[0068] Specifically, the checksum corresponding to the backed-up portion of the second system program matches the checksum of the corresponding portion of the first system program. Therefore, in cases where the checksum of the second system program is inconsistent with the checksum of the first system program, the portion of the system program corresponding to the inconsistent checksum is designated as a breakpoint. Figure 4 As shown, the above-mentioned receiving array is called to continue the backup process from the breakpoint, thus avoiding duplicate backups.

[0069] To enable flexible backup options, in one optional implementation, after step S204, the method further includes:

[0070] Step S601: Determine if there is a request to start the OTA flashing process;

[0071] Specifically, when a flashing process is in progress, the aforementioned receiving array is occupied, so the aforementioned backup process cannot be performed simultaneously. Therefore, before continuing the backup, it is necessary to determine whether the platform or the user has issued a request to start the aforementioned OTA flashing process.

[0072] In step S602, if there is no startup request, the backup process is continued by calling the receiving array; if there is a startup request and the checksum of the first system program is inconsistent with the checksum of the corresponding second system program, the backup process is continued by using the Bootloader.

[0073] Specifically, such as Figure 4 As shown, when no OTA flashing process start request is issued, the aforementioned receive array is not occupied, so the backup process can be directly called using the receive array. However, when an OTA flashing process start request is issued, the receive array is occupied and cannot be used for the backup process. In this case, calling the Bootloader will compare the checksum of the first system program with the checksum of the corresponding second system program. If a discrepancy is found, the Bootloader will continue the backup process. At this time, the Bootloader is in boot loading mode, and what it does is load the operating system from a solid-state storage device on the target host into RAM. In this case, the Bootloader's function is equivalent to the aforementioned receive array.

[0074] To enable those skilled in the art to better understand the technical solution of this application, the implementation process of the OTA backup method of this application will be described in detail below with reference to specific embodiments.

[0075] This embodiment relates to a specific OTA backup method, such as... Figure 5 As shown, it includes the following steps:

[0076] Step S1: Divide the external Flash into two areas, named Flash and Flash_copy. Flash is used to store programs and data downloaded from the cloud platform, and Flash_copy is used to back up the EMS area of ​​the current ECU.

[0077] Step S2: During ECU operation, check whether the checksums of the external Flash and EMS areas are consistent;

[0078] Step S3: If an inconsistency is detected, back up the corresponding area to an external Flash copy;

[0079] Step S4: During the backup process, continuously check if the cloud platform is downloading program files. If a download operation occurs, stop the backup process.

[0080] Step S5: After the download is complete, if there is free time, check whether the checksum of each partition of the current Flash_Copy is consistent with the checksum of the current EMS program, and continue the backup from the partition that is inconsistent.

[0081] Step S6: If directly jumping into the Bootloader for flashing, check whether the checksum of each partition in the current Flash_Copy is consistent with the checksum of the current EMS program. If they are inconsistent, perform a backup in the Bootloader.

[0082] This application also provides an OTA backup device. It should be noted that the OTA backup device of this application can be used to execute the OTA backup method provided in this application. This device is used to implement the above embodiments and preferred embodiments; details already described will not be repeated. As used below, the term "module" can refer to a combination of software and / or hardware that implements a predetermined function. Although the device described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.

[0083] The following describes the OTA backup device provided in the embodiments of this application.

[0084] Figure 6 This is a schematic diagram of an OTA backup device according to an embodiment of this application. Figure 6As shown, the device includes:

[0085] The first comparison unit 10 is used to determine whether the first system program and the second system program are consistent. The first system program is the system program running on the EMS, and the second system program is the system program stored in the first storage partition. The first storage partition is a storage partition in the external flash memory of the ECU.

[0086] Specifically, the aforementioned EMS refers to the engine management system of an automobile. The first system program is the software program stored in the EMS area of ​​the ECU's built-in Flash memory, used to enable the engine management system to control the engine. The second system program is the system program stored in the Flash area of ​​the ECU's external Flash memory; this Flash area is the first storage partition mentioned above. Figure 4 As shown, updating the system program in the EMS area requires comparing the first system program and the second system program to determine if their versions are consistent, that is, to determine if the system program running in the EMS is the latest version.

[0087] The first processing unit 20 is used to, in the event that the first system program and the second system program are inconsistent, at least call the receiving array to execute the backup process. The receiving array is used to store data in random access memory. The backup process is used to temporarily store the first system program in random access memory and then back it up to the second storage partition. The second storage partition is another storage partition in the external flash memory of the ECU.

[0088] Specifically, such as Figure 4 As shown, if the first system program and the second system program are inconsistent, it can be determined that the first system program is not the latest version. In this case, the first system program needs to be updated. To avoid ECU malfunctions due to flashing during the update process, which would render the ECU unrepairable, the current first system program running in the EMS (Electronic Storage System), i.e., the old version, needs to be backed up for backup. The backup process requires calling the receive array to temporarily store the first system program in the random access memory (RAM), i.e., the common RAM in the ECU of this application. Then, the ECU stores the first system program from the common RAM into the Flash copy area in the ECU's external Flash memory. This Flash copy area is the second storage partition.

[0089] The first judgment unit 30 is used to determine whether there is a download process in the process executed by the above receiving array when the backup process is running. The download process is used to download the third system program and update the second system program in the first storage partition through the third system program. The third system program is a system program sent by the cloud platform to the ECU.

[0090] Specifically, to improve memory resource utilization efficiency, the backup process and the download process in this application use the same receive array. Therefore, to prevent conflicts and data errors between the backup process and the download process, this application proposes a priority order for the download process. Figure 4 As shown, during the backup process described above, it is necessary to determine whether the download process is present in the receiving array. The download process involves downloading the new version of the system program from the cloud platform to the Flash area of ​​the ECU's external Flash memory. This means temporarily storing the third system program in the common RAM, and then the ECU stores the third system program from the common RAM into the Flash area, overwriting the second system program.

[0091] The second processing unit 40 is configured to pause the backup process when the download process exists and the download process is running in the process executed by the receiving array, until the receiving array finishes executing the download process, and then call the receiving array to continue executing the backup process.

[0092] Specifically, if it is determined that the download process is one of the processes running in the aforementioned receiving array, in order to prevent the backup process from conflicting with the download process and causing data errors, such as... Figure 4 As shown, the ongoing backup process is paused, and then resumed after the download process is completed, provided that the platform or customer does not immediately update the system programs running in EMS. This avoids duplicate backups of the already backed-up portion due to inconsistencies between the backed-up first system program and the overwritten second system program.

[0093] Applying the technical solution of this application, the first comparison unit is used to determine whether the first system program and the second system program are consistent. The first system program is the system program running on the EMS, and the second system program is the system program stored in the first storage partition, which is a storage partition in the external flash memory of the ECU. The first processing unit is used to, in the case that the first system program and the second system program are inconsistent, at least call the receiving array to execute the backup process. The receiving array is used to store the data in random access memory, and the backup process is used to temporarily store the first system program in random access memory and then back it up to the second storage partition, which is the external flash memory of the ECU. Another storage partition in the external flash memory of U; the first judgment unit is used to determine whether there is a download process in the process executed by the above-mentioned receiving array when the backup process is running. The download process is used to download the third system program and update the second system program in the above-mentioned first storage partition through the third system program. The third system program is the system program issued by the cloud platform to the above-mentioned ECU; the second processing unit is used to pause the above-mentioned backup process when there is the download process in the process executed by the above-mentioned receiving array and the download process is running, until the above-mentioned receiving array finishes executing the download process, and then call the above-mentioned receiving array to continue executing the backup process. This method uses a receiving array for backup and download to improve the utilization efficiency of memory resources. To avoid conflicts between backup and download, a download priority solution is proposed. Backup continues during idle time after the download is completed. The flexible backup solution solves the problem of duplicate backup caused by backup first and then download in the prior art, and also ensures the stability of the OTA process.

[0094] To determine whether to execute the backup process described above, in one optional implementation, the first processing unit includes:

[0095] The acquisition module is used to acquire the checksum of the first system program and the checksum of the second system program corresponding to the first system program. The checksum is used to identify the system program version. The checksum includes at least a first checksum and a second checksum. The first checksum is the checksum included in the first system program, and the second checksum is the checksum included in the second system program.

[0096] Specifically, the first system program is stored in the EMS area. Different functions of the first system program are stored in different secondary partitions within the EMS area, such as the program area, calibration area, and multiple EOL areas. The EOL area is the project termination area, used to terminate the process. Different partitions have different checksums, and the second system program also has a corresponding checksum. These checksums are used to distinguish system versions, functioning similarly to a version number.

[0097] The determining module is configured to determine that the first system program and the second system program are consistent if the checksum of the first system program and the checksum of the second system program corresponding to the first system program are consistent, and to determine that the first system program and the second system program are inconsistent if the checksum of the first system program and the checksum of the second system program corresponding to the first system program are inconsistent.

[0098] Specifically, since the first checksum used to identify the system version corresponds one-to-one with the second checksum, if the corresponding parts of the first checksum and the second checksum are the same, it means that the first system program and the second system program are in the same version; if the corresponding parts of the first checksum and the second checksum are not the same, it means that the first system program and the second system program are in different versions.

[0099] In order to determine whether to accept the new system issued by the cloud platform, in one optional implementation, the above-mentioned device further includes:

[0100] The first acquisition unit is used to acquire the first checksum and the third checksum before determining whether there is a download process in the process executed by the above-mentioned receiving array. The third checksum is the checksum contained in the above-mentioned third system program.

[0101] Specifically, such as Figure 4 As shown, after the system program is distributed on the cloud platform, it is necessary to first determine whether the version distributed by the cloud platform is a new version relative to the version running in the EMS. Therefore, it is necessary to obtain the checksum of the system program distributed by the cloud platform, i.e., the checksum of the third system program, and compare it with the checksum of the first system program to determine whether the versions of the third system program and the first system program are consistent.

[0102] The second acquisition unit is used to acquire the name of the third storage partition and the name of the fourth storage partition. The third storage partition is the storage partition in the built-in flash memory of the ECU requested by the third system program, and the fourth storage partition is the storage partition in the built-in flash memory of the ECU occupied by the first system program.

[0103] Specifically, such as Figure 4As shown, obtaining the name of the storage partition requested by the third system program is equivalent to obtaining the corresponding location of the EMS area occupied by the third system program when it runs in the EMS. Comparing the name of the third storage partition with the name of the fourth storage partition is equivalent to determining whether the address range occupied by the third system program and the first system program during runtime is consistent. Only if they are consistent can the third system program be adapted to the ECU. If they are inconsistent, it proves that the third system program cannot run smoothly in the ECU.

[0104] The third processing unit is used to invoke the receiving array to execute the download process when the first checksum is inconsistent with the third checksum and the name of the third storage partition is consistent with the name of the fourth storage partition.

[0105] Specifically, such as Figure 4 As shown, if the first checksum and the third checksum are inconsistent, and the name of the third storage partition is the same as the name of the fourth storage partition, it indicates that the third system program is a new system relative to the first system program, and that the third system program is compatible with the ECU. Therefore, at least the receiving array is invoked to complete the download process, and the third system program is stored in the third storage partition for later use.

[0106] To ensure the smooth progress of system program updates, in one optional implementation, the above-mentioned device further includes:

[0107] The detection unit is used to detect whether there is an OTA flashing status variable in the random access memory after the download process is completed in the receiving array. The OTA flashing status variable is generated by the random access memory when the flashing operation performed in the download process is normal. The flashing operation is used to update the first system program.

[0108] Specifically, to prevent abnormal flashing operations from causing abnormal updates to the system program in the ECU, which could lead to ECU malfunction, such as... Figure 4 As shown, the above-mentioned OTA flashing status variable needs to be generated in the public RAM before the flashing operation is performed to indicate that the flashing operation is proceeding normally.

[0109] The second judgment unit is used to determine that the flashing operation performed by the download process is normal when the above-mentioned OTA flashing status variable exists, and to call the Bootloader to obtain the above-mentioned third system program from the above-mentioned first storage partition, and to update the above-mentioned first system program according to the above-mentioned third system program. The above-mentioned Bootloader is a bootloader program for updating the above-mentioned first system program.

[0110] Specifically, such as Figure 4As shown, if the aforementioned OTA flashing status variable exists in the public RAM, it indicates that the upcoming flashing operation is a normal operation. At this point, the flashing operation begins. First, the Bootloader is invoked to load the third system program from the external Flash memory into RAM via network communication. Then, the third system program is written to the third storage partition, completing the update of the first system program. During this operation, the Bootloader program is in download mode, performing the function of downloading the kernel image and root file system image from the development host to RAM via serial port or network communication, and then writing the kernel image and root file system image to the solid-state storage media of the target host.

[0111] In an optional embodiment, to address the malfunctions caused by the aforementioned third system program, the apparatus further includes:

[0112] The fourth processing unit is configured to, after detecting whether the random access memory has an OTA flashing status variable, and if a predetermined condition is met or if it is detected that the OTA flashing status variable does not exist, call the Bootloader to obtain the fourth system program from the second storage partition, and update the third system program according to the fourth system program. The fourth system program is obtained by the backup process from the first system program. The predetermined condition is that an abnormal power failure occurs during the flashing process of the random access memory or the third system program runs abnormally.

[0113] Specifically, such as Figure 4 As shown, if the OTA flashing status variable was not detected before the flashing operation was performed, or if a power outage or abnormal operation of the third system program occurred during the flashing process, i.e., the ECU malfunctioned due to a system program issue, a rollback operation is performed. This involves flashing the system program backed up to the Flash copy area (i.e., the fourth system data) to the EMS area. This restores the system in the ECU to its state before the update, resolving the aforementioned fault.

[0114] To avoid duplicate backups, in one optional implementation, the second processing unit includes:

[0115] The acquisition module is used to acquire the checksum of the first system program and the checksum of the second system program corresponding to the first system program.

[0116] Specifically, in order to solve the problem of duplicate backups, this application implements the function of resuming interrupted downloads. To determine the breakpoint of the backup process, it is necessary to obtain the checksum of the first system program and compare it with the checksum of the second system program.

[0117] If the checksum of the first system program and the checksum of the second system program corresponding to the first system program are inconsistent, the processing module calls the receiving array to continue executing the backup process.

[0118] Specifically, the checksum corresponding to the backed-up portion of the second system program matches the checksum of the corresponding portion of the first system program. Therefore, in cases where the checksum of the second system program is inconsistent with the checksum of the first system program, the portion of the system program corresponding to the inconsistent checksum is designated as a breakpoint. Figure 4 As shown, the above-mentioned receiving array is called to continue the backup process from the breakpoint, thus avoiding duplicate backups.

[0119] To enable flexible backup options, in one optional implementation, the above-mentioned apparatus further includes:

[0120] The third judgment unit is used to determine whether there is an OTA flashing process start request after the download process is completed in the receiving array.

[0121] Specifically, when a flashing process is in progress, the aforementioned receiving array is occupied, so the aforementioned backup process cannot be performed simultaneously. Therefore, before continuing the backup, it is necessary to determine whether the platform or the user has issued a request to start the aforementioned OTA flashing process.

[0122] The fifth processing unit is used to continue executing the backup process by calling the receiving array when there is no startup request; and to continue executing the backup process using the Bootloader when there is a startup request and the checksum of the first system program is inconsistent with the checksum of the corresponding second system program.

[0123] Specifically, such as Figure 4 As shown, when no OTA flashing process start request is issued, the aforementioned receive array is not occupied, so the backup process can be directly called using the receive array. However, when an OTA flashing process start request is issued, the receive array is occupied and cannot be used for the backup process. In this case, calling the Bootloader will compare the checksum of the first system program with the checksum of the corresponding second system program. If a discrepancy is found, the Bootloader will continue the backup process. At this time, the Bootloader is in boot loading mode, and what it does is load the operating system from a solid-state storage device on the target host into RAM. In this case, the Bootloader's function is equivalent to the aforementioned receive array.

[0124] The aforementioned OTA backup device includes a processor and a memory. The first comparison unit, first processing unit, first judgment unit, and second processing unit are all stored as program units in the memory. The processor executes the program units stored in the memory to implement the corresponding functions. All of the above modules are located in the same processor; or, the above modules are located in different processors in any combination.

[0125] The processor contains a kernel, which retrieves the corresponding program units from memory. One or more kernels can be configured, and duplicate backups can be avoided by adjusting kernel parameters.

[0126] The memory may include non-permanent memory in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM, and the memory includes at least one memory chip.

[0127] This invention provides a computer-readable storage medium including a stored program, wherein, when the program is executed, it controls the device where the computer-readable storage medium is located to perform the OTA backup method.

[0128] Specifically, OTA backup methods include:

[0129] Step S201: Determine whether the first system program and the second system program are consistent. The first system program is the system program running on the EMS, and the second system program is the system program stored in the first storage partition. The first storage partition is a storage partition in the external flash memory of the ECU.

[0130] Specifically, the aforementioned EMS refers to the engine management system of an automobile. The first system program is the software program stored in the EMS area of ​​the ECU's built-in Flash memory, used to enable the engine management system to control the engine. The second system program is the system program stored in the Flash area of ​​the ECU's external Flash memory, which is the first storage partition. The system program that updates the system program in the EMS area is compared with the first system program to determine if their versions are consistent, that is, to determine whether the system program running in the EMS is the latest version.

[0131] Step S202: In the case that the first system program and the second system program are inconsistent, at least the receiving array is called to execute the backup process. The receiving array is used to store data in random access memory. The backup process is used to temporarily store the first system program in random access memory and then back it up to the second storage partition. The second storage partition is another storage partition in the external flash memory of the ECU.

[0132] Specifically, if the first system program and the second system program are inconsistent, it can be determined that the first system program is not the latest version. In this case, the first system program needs to be updated. To avoid the ECU malfunctioning and becoming unrepairable due to rewriting during the update process, the first system program currently running in the EMS, i.e., the old version, needs to be backed up for backup. The backup process requires calling the receive array to temporarily store the first system program in the random access memory, i.e., the common RAM in the ECU of this application. Then, the ECU stores the first system program in the common RAM into the Flash copy area in the ECU's external Flash memory. The Flash copy area is the second storage partition.

[0133] Step S203: When the backup process is running, determine whether there is a download process in the process executed by the above receiving array. The download process is used to download the third system program and update the second system program in the first storage partition through the third system program. The third system program is the system program sent by the cloud platform to the ECU.

[0134] Specifically, to improve memory resource utilization efficiency, the backup process and the download process in this application use the same receive array. Therefore, to prevent conflicts and data errors between the backup process and the download process, this application proposes a priority order for the download process. Thus, during the backup process, it is necessary to determine whether the download process is running in the receive array. The download process involves downloading the new version of the system program distributed by the cloud platform to the Flash area of ​​the ECU's external Flash, temporarily storing the third system program in the common RAM, and then the ECU stores the third system program from the common RAM into the Flash area, overwriting the second system program.

[0135] Step S204: If the download process exists and is running in the process executed by the receiving array, pause the backup process until the receiving array finishes executing the download process, and then call the receiving array to continue executing the backup process.

[0136] Specifically, if it is determined that the download process is running in the aforementioned receiving array, to prevent conflicts between the backup process and the download process and the resulting data errors, the ongoing backup process is paused. Then, after the download process is completed, and if the platform or customer does not immediately update the system programs running in the EMS, the backup process resumes. This avoids the situation where, after backing up a portion of the first system program, there is inconsistency between the backed-up portion and the overwritten second system program, resulting in duplicate backups of the already backed-up portion.

[0137] Optionally, in step S2021, the checksum of the first system program is obtained, and the checksum of the second system program corresponding to the first system program is obtained. The checksum is used to identify the system program version. The checksum includes at least a first checksum and a second checksum. The first checksum is the checksum included in the first system program, and the second checksum is the checksum included in the second system program. In step S2022, if the checksum of the first system program and the checksum of the second system program corresponding to the first system program are consistent, it is determined that the first system program and the second system program are consistent. If the checksum of the first system program and the checksum of the second system program corresponding to the first system program are inconsistent, it is determined that the first system program and the second system program are inconsistent.

[0138] Optionally, in step S301, the first checksum and the third checksum are obtained, wherein the third checksum is the checksum included in the third system program; in step S302, the name of the third storage partition and the name of the fourth storage partition are obtained, wherein the third storage partition is the storage partition in the built-in flash memory of the ECU requested by the third system program, and the fourth storage partition is the storage partition in the built-in flash memory of the ECU occupied by the first system program; in step S303, if the first checksum and the third checksum are inconsistent and the name of the third storage partition is consistent with the name of the fourth storage partition, the receiving array is invoked to execute the download process.

[0139] Optionally, in step S401, it is detected whether the above-mentioned random access memory has an OTA flashing status variable. The above-mentioned OTA flashing status variable is generated by the above-mentioned random access memory when the flashing operation performed by the above-mentioned download process is normal. The above-mentioned flashing operation is used to update the above-mentioned first system program. In step S402, if the above-mentioned OTA flashing status variable exists, it is determined that the flashing operation performed by the above-mentioned download process is normal. The Bootloader is called to obtain the above-mentioned third system program from the above-mentioned first storage partition, and the above-mentioned first system program is updated according to the above-mentioned third system program. The above-mentioned Bootloader is a bootloader program for updating the above-mentioned first system program.

[0140] Optionally, in step S501, if a predetermined condition is met or if it is detected that the above-mentioned OTA flashing status variable does not exist, the above-mentioned Bootloader is invoked to obtain the fourth system program from the above-mentioned second storage partition, and the above-mentioned third system program is updated according to the above-mentioned fourth system program. The above-mentioned fourth system program is obtained by the above-mentioned backup process from the above-mentioned first system program. The above-mentioned predetermined condition is that an abnormal power failure occurs during the flashing process of the above-mentioned random access memory or the above-mentioned third system program runs abnormally.

[0141] Optionally, in step S2041, the checksum of the first system program is obtained, and the checksum of the second system program corresponding to the first system program is obtained; in step S2042, if the checksum of the first system program and the checksum of the second system program corresponding to the first system program are inconsistent, the receiving array is called to continue executing the backup process.

[0142] Optionally, in step S601, it is determined whether there is an OTA flashing process startup request; in step S602, if there is no startup request, the backup process is continued by calling the receiving array; if there is a startup request and the checksum of the first system program is inconsistent with the checksum of the corresponding second system program, the backup process is continued by using the Bootloader.

[0143] This invention provides a processor for running a program, wherein the program executes the OTA backup method.

[0144] Specifically, OTA backup methods include:

[0145] Step S201: Determine whether the first system program and the second system program are consistent. The first system program is the system program running on the EMS, and the second system program is the system program stored in the first storage partition. The first storage partition is a storage partition in the external flash memory of the ECU.

[0146] Specifically, the aforementioned EMS refers to the engine management system of an automobile. The first system program is the software program stored in the EMS area of ​​the ECU's built-in Flash memory, used to enable the engine management system to control the engine. The second system program is the system program stored in the Flash area of ​​the ECU's external Flash memory, which is the first storage partition. The system program that updates the system program in the EMS area is compared with the first system program to determine if their versions are consistent, that is, to determine whether the system program running in the EMS is the latest version.

[0147] Step S202: In the case that the first system program and the second system program are inconsistent, at least the receiving array is called to execute the backup process. The receiving array is used to store data in random access memory. The backup process is used to temporarily store the first system program in random access memory and then back it up to the second storage partition. The second storage partition is another storage partition in the external flash memory of the ECU.

[0148] Specifically, if the first system program and the second system program are inconsistent, it can be determined that the first system program is not the latest version. In this case, the first system program needs to be updated. To avoid the ECU malfunctioning and becoming unrepairable due to rewriting during the update process, the first system program currently running in the EMS, i.e., the old version, needs to be backed up for backup. The backup process requires calling the receive array to temporarily store the first system program in the random access memory, i.e., the common RAM in the ECU of this application. Then, the ECU stores the first system program in the common RAM into the Flash copy area in the ECU's external Flash memory. The Flash copy area is the second storage partition.

[0149] Step S203: When the backup process is running, determine whether there is a download process in the process executed by the above receiving array. The download process is used to download the third system program and update the second system program in the first storage partition through the third system program. The third system program is the system program sent by the cloud platform to the ECU.

[0150] Specifically, to improve memory resource utilization efficiency, the backup process and the download process in this application use the same receive array. Therefore, to prevent conflicts and data errors between the backup process and the download process, this application proposes a priority order for the download process. Thus, during the backup process, it is necessary to determine whether the download process is running in the receive array. The download process involves downloading the new version of the system program distributed by the cloud platform to the Flash area of ​​the ECU's external Flash, temporarily storing the third system program in the common RAM, and then the ECU stores the third system program from the common RAM into the Flash area, overwriting the second system program.

[0151] Step S204: If the download process exists and is running in the process executed by the receiving array, pause the backup process until the receiving array finishes executing the download process, and then call the receiving array to continue executing the backup process.

[0152] Specifically, if it is determined that the download process is running in the aforementioned receiving array, to prevent conflicts between the backup process and the download process and the resulting data errors, the ongoing backup process is paused. Then, after the download process is completed, and if the platform or customer does not immediately update the system programs running in the EMS, the backup process resumes. This avoids the situation where, after backing up a portion of the first system program, there is inconsistency between the backed-up portion and the overwritten second system program, resulting in duplicate backups of the already backed-up portion.

[0153] Optionally, in step S2021, the checksum of the first system program is obtained, and the checksum of the second system program corresponding to the first system program is obtained. The checksum is used to identify the system program version. The checksum includes at least a first checksum and a second checksum. The first checksum is the checksum included in the first system program, and the second checksum is the checksum included in the second system program. In step S2022, if the checksum of the first system program and the checksum of the second system program corresponding to the first system program are consistent, it is determined that the first system program and the second system program are consistent. If the checksum of the first system program and the checksum of the second system program corresponding to the first system program are inconsistent, it is determined that the first system program and the second system program are inconsistent.

[0154] Optionally, in step S301, the first checksum and the third checksum are obtained, wherein the third checksum is the checksum included in the third system program; in step S302, the name of the third storage partition and the name of the fourth storage partition are obtained, wherein the third storage partition is the storage partition in the built-in flash memory of the ECU requested by the third system program, and the fourth storage partition is the storage partition in the built-in flash memory of the ECU occupied by the first system program; in step S303, if the first checksum and the third checksum are inconsistent and the name of the third storage partition is consistent with the name of the fourth storage partition, the receiving array is invoked to execute the download process.

[0155] Optionally, in step S401, it is detected whether the above-mentioned random access memory has an OTA flashing status variable. The above-mentioned OTA flashing status variable is generated by the above-mentioned random access memory when the flashing operation performed by the above-mentioned download process is normal. The above-mentioned flashing operation is used to update the above-mentioned first system program. In step S402, if the above-mentioned OTA flashing status variable exists, it is determined that the flashing operation performed by the above-mentioned download process is normal. The Bootloader is called to obtain the above-mentioned third system program from the above-mentioned first storage partition, and the above-mentioned first system program is updated according to the above-mentioned third system program. The above-mentioned Bootloader is a bootloader program for updating the above-mentioned first system program.

[0156] Optionally, in step S501, if a predetermined condition is met or if it is detected that the above-mentioned OTA flashing status variable does not exist, the above-mentioned Bootloader is invoked to obtain the fourth system program from the above-mentioned second storage partition, and the above-mentioned third system program is updated according to the above-mentioned fourth system program. The above-mentioned fourth system program is obtained by the above-mentioned backup process from the above-mentioned first system program. The above-mentioned predetermined condition is that an abnormal power failure occurs during the flashing process of the above-mentioned random access memory or the above-mentioned third system program runs abnormally.

[0157] Optionally, in step S2041, the checksum of the first system program is obtained, and the checksum of the second system program corresponding to the first system program is obtained; in step S2042, if the checksum of the first system program and the checksum of the second system program corresponding to the first system program are inconsistent, the receiving array is called to continue executing the backup process.

[0158] Optionally, in step S601, it is determined whether there is an OTA flashing process startup request; in step S602, if there is no startup request, the backup process is continued by calling the receiving array; if there is a startup request and the checksum of the first system program is inconsistent with the checksum of the corresponding second system program, the backup process is continued by using the Bootloader.

[0159] This invention provides a device including a processor, a memory, and a program stored in the memory and executable on the processor. When the processor executes the program, it performs at least the following steps:

[0160] Step S201: Determine whether the first system program and the second system program are consistent. The first system program is the system program running on the EMS, and the second system program is the system program stored in the first storage partition. The first storage partition is a storage partition in the external flash memory of the ECU.

[0161] Step S202: In the case that the first system program and the second system program are inconsistent, at least the receiving array is called to execute the backup process. The receiving array is used to store data in random access memory. The backup process is used to temporarily store the first system program in random access memory and then back it up to the second storage partition. The second storage partition is another storage partition in the external flash memory of the ECU.

[0162] Step S203: When the backup process is running, determine whether there is a download process in the process executed by the above receiving array. The download process is used to download the third system program and update the second system program in the first storage partition through the third system program. The third system program is the system program sent by the cloud platform to the ECU.

[0163] Step S204: If the download process exists and is running in the process executed by the receiving array, pause the backup process until the receiving array finishes executing the download process, and then call the receiving array to continue executing the backup process.

[0164] The devices mentioned in this article can be servers, PCs, tablets, mobile phones, etc.

[0165] Optionally, in step S2021, the checksum of the first system program is obtained, and the checksum of the second system program corresponding to the first system program is obtained. The checksum is used to identify the system program version. The checksum includes at least a first checksum and a second checksum. The first checksum is the checksum included in the first system program, and the second checksum is the checksum included in the second system program. In step S2022, if the checksum of the first system program and the checksum of the second system program corresponding to the first system program are consistent, it is determined that the first system program and the second system program are consistent. If the checksum of the first system program and the checksum of the second system program corresponding to the first system program are inconsistent, it is determined that the first system program and the second system program are inconsistent.

[0166] Optionally, in step S301, the first checksum and the third checksum are obtained, wherein the third checksum is the checksum included in the third system program; in step S302, the name of the third storage partition and the name of the fourth storage partition are obtained, wherein the third storage partition is the storage partition in the built-in flash memory of the ECU requested by the third system program, and the fourth storage partition is the storage partition in the built-in flash memory of the ECU occupied by the first system program; in step S303, if the first checksum and the third checksum are inconsistent and the name of the third storage partition is consistent with the name of the fourth storage partition, the receiving array is invoked to execute the download process.

[0167] Optionally, in step S401, it is detected whether the above-mentioned random access memory has an OTA flashing status variable. The above-mentioned OTA flashing status variable is generated by the above-mentioned random access memory when the flashing operation performed by the above-mentioned download process is normal. The above-mentioned flashing operation is used to update the above-mentioned first system program. In step S402, if the above-mentioned OTA flashing status variable exists, it is determined that the flashing operation performed by the above-mentioned download process is normal. The Bootloader is called to obtain the above-mentioned third system program from the above-mentioned first storage partition, and the above-mentioned first system program is updated according to the above-mentioned third system program. The above-mentioned Bootloader is a bootloader program for updating the above-mentioned first system program.

[0168] Optionally, in step S501, if a predetermined condition is met or if it is detected that the above-mentioned OTA flashing status variable does not exist, the above-mentioned Bootloader is invoked to obtain the fourth system program from the above-mentioned second storage partition, and the above-mentioned third system program is updated according to the above-mentioned fourth system program. The above-mentioned fourth system program is obtained by the above-mentioned backup process from the above-mentioned first system program. The above-mentioned predetermined condition is that an abnormal power failure occurs during the flashing process of the above-mentioned random access memory or the above-mentioned third system program runs abnormally.

[0169] Optionally, in step S2041, the checksum of the first system program is obtained, and the checksum of the second system program corresponding to the first system program is obtained; in step S2042, if the checksum of the first system program and the checksum of the second system program corresponding to the first system program are inconsistent, the receiving array is called to continue executing the backup process.

[0170] Optionally, in step S601, it is determined whether there is an OTA flashing process startup request; in step S602, if there is no startup request, the backup process is continued by calling the receiving array; if there is a startup request and the checksum of the first system program is inconsistent with the checksum of the corresponding second system program, the backup process is continued by using the Bootloader.

[0171] This application also provides a computer program product, which, when executed on a data processing device, is suitable for executing an initialization program having at least the following method steps:

[0172] Step S201: Determine whether the first system program and the second system program are consistent. The first system program is the system program running on the EMS, and the second system program is the system program stored in the first storage partition. The first storage partition is a storage partition in the external flash memory of the ECU.

[0173] Step S202: In the case that the first system program and the second system program are inconsistent, at least the receiving array is called to execute the backup process. The receiving array is used to store data in random access memory. The backup process is used to temporarily store the first system program in random access memory and then back it up to the second storage partition. The second storage partition is another storage partition in the external flash memory of the ECU.

[0174] Step S203: When the backup process is running, determine whether there is a download process in the process executed by the above receiving array. The download process is used to download the third system program and update the second system program in the first storage partition through the third system program. The third system program is the system program sent by the cloud platform to the ECU.

[0175] Step S204: If the download process exists and is running in the process executed by the receiving array, pause the backup process until the receiving array finishes executing the download process, and then call the receiving array to continue executing the backup process.

[0176] Optionally, in step S2021, the checksum of the first system program is obtained, and the checksum of the second system program corresponding to the first system program is obtained. The checksum is used to identify the system program version. The checksum includes at least a first checksum and a second checksum. The first checksum is the checksum included in the first system program, and the second checksum is the checksum included in the second system program. In step S2022, if the checksum of the first system program and the checksum of the second system program corresponding to the first system program are consistent, it is determined that the first system program and the second system program are consistent. If the checksum of the first system program and the checksum of the second system program corresponding to the first system program are inconsistent, it is determined that the first system program and the second system program are inconsistent.

[0177] Optionally, in step S301, the first checksum and the third checksum are obtained, wherein the third checksum is the checksum included in the third system program; in step S302, the name of the third storage partition and the name of the fourth storage partition are obtained, wherein the third storage partition is the storage partition in the built-in flash memory of the ECU requested by the third system program, and the fourth storage partition is the storage partition in the built-in flash memory of the ECU occupied by the first system program; in step S303, if the first checksum and the third checksum are inconsistent and the name of the third storage partition is consistent with the name of the fourth storage partition, the receiving array is invoked to execute the download process.

[0178] Optionally, in step S401, it is detected whether the above-mentioned random access memory has an OTA flashing status variable. The above-mentioned OTA flashing status variable is generated by the above-mentioned random access memory when the flashing operation performed by the above-mentioned download process is normal. The above-mentioned flashing operation is used to update the above-mentioned first system program. In step S402, if the above-mentioned OTA flashing status variable exists, it is determined that the flashing operation performed by the above-mentioned download process is normal. The Bootloader is called to obtain the above-mentioned third system program from the above-mentioned first storage partition, and the above-mentioned first system program is updated according to the above-mentioned third system program. The above-mentioned Bootloader is a bootloader program for updating the above-mentioned first system program.

[0179] Optionally, in step S501, if a predetermined condition is met or if it is detected that the above-mentioned OTA flashing status variable does not exist, the above-mentioned Bootloader is invoked to obtain the fourth system program from the above-mentioned second storage partition, and the above-mentioned third system program is updated according to the above-mentioned fourth system program. The above-mentioned fourth system program is obtained by the above-mentioned backup process from the above-mentioned first system program. The above-mentioned predetermined condition is that an abnormal power failure occurs during the flashing process of the above-mentioned random access memory or the above-mentioned third system program runs abnormally.

[0180] Optionally, in step S2041, the checksum of the first system program is obtained, and the checksum of the second system program corresponding to the first system program is obtained; in step S2042, if the checksum of the first system program and the checksum of the second system program corresponding to the first system program are inconsistent, the receiving array is called to continue executing the backup process.

[0181] Optionally, in step S601, it is determined whether there is an OTA flashing process startup request; in step S602, if there is no startup request, the backup process is continued by calling the receiving array; if there is a startup request and the checksum of the first system program is inconsistent with the checksum of the corresponding second system program, the backup process is continued by using the Bootloader.

[0182] It is obvious to those skilled in the art that the modules or steps of the present invention described above can be implemented using general-purpose computing devices. They can be centralized on a single computing device or distributed across a network of multiple computing devices. They can be implemented using computer-executable program code, and thus can be stored in a storage device for execution by a computing device. In some cases, the steps shown or described can be performed in a different order than those described herein, or they can be fabricated as separate integrated circuit modules, or multiple modules or steps can be fabricated as a single integrated circuit module. Thus, the present invention is not limited to any particular combination of hardware and software.

[0183] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application 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, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0184] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. 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 device that provides the functions specified in one or more boxes.

[0185] 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 instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

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

[0187] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0188] Memory may include non-persistent memory in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, like read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0189] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0190] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0191] As can be seen from the above description, the embodiments of this application achieve the following technical effects:

[0192] 1) The OTA backup method of this application, applying the technical solution of this application, firstly, determines whether the first system program and the second system program are consistent. The first system program is the system program running on the EMS, and the second system program is the system program stored in the first storage partition, which is a storage partition in the external flash memory of the ECU. Then, if the first system program and the second system program are inconsistent, at least the receiving array is called to execute the backup process. The receiving array is used to store data in random access memory, and the backup process is used to temporarily store the first system program in random access memory and then back it up to the second storage partition. The storage partition is another storage partition in the external flash memory of the aforementioned ECU. Then, while the backup process is running, it is determined whether a download process exists within the processes executed by the aforementioned receiving array. This download process downloads a third system program and updates the second system program in the aforementioned first storage partition using this third system program. The third system program is a system program distributed by the cloud platform to the aforementioned ECU. Finally, if the download process exists within the processes executed by the aforementioned receiving array and is running, the backup process is paused until the download process is completed by the aforementioned receiving array, at which point the receiving array is invoked to continue executing the backup process. This method uses a single receiving array for backup and download, improving memory resource utilization efficiency. To avoid conflicts between backup and download, a download-first solution is proposed, allowing backup to continue during idle time after download completion. This flexible backup scheme solves the problem of duplicate backups caused by backing up before downloading in existing technologies and also ensures the stability of the OTA process.

[0193] 2) The OTA backup device of this application, applying the technical solution of this application, has a first comparison unit used to determine whether the first system program and the second system program are consistent. The first system program is the system program running on the EMS, and the second system program is the system program stored in the first storage partition, which is a storage partition in the external flash memory of the ECU. The first processing unit is used to, in the case that the first system program and the second system program are inconsistent, at least call the receiving array to execute the backup process. The receiving array is used to store the data in random access memory. The backup process is used to temporarily store the first system program in random access memory and then back it up to the second storage partition. The storage partition is another storage partition in the external flash memory of the ECU. The first judgment unit is used to determine whether a download process exists in the process executed by the receiving array when the backup process is running. The download process is used to download a third system program and update the second system program in the first storage partition through the third system program. The third system program is a system program sent by the cloud platform to the ECU. The second processing unit is used to pause the backup process when the download process exists in the process executed by the receiving array and the download process is running, until the receiving array finishes executing the download process, and then call the receiving array to continue executing the backup process. This method uses a single receiving array for backup and download to improve the utilization efficiency of memory resources. To avoid conflicts between backup and download, a download-first solution is proposed. Backup continues during idle time after download is completed. This flexible backup solution solves the problem of duplicate backups caused by backing up first and then downloading in the prior art, and also ensures the stability of the OTA process.

[0194] The above description is merely a preferred embodiment of this application and is not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, or improvements made within the spirit and principles of this application should be included within the scope of protection of this application.

Claims

1. An OTA backup method, characterized in that, include: Determine whether the first system program and the second system program are consistent. The first system program is the system program running on the EMS, and the second system program is the system program stored in the first storage partition. The first storage partition is a storage partition in the external flash memory of the ECU. In the event that the first system program and the second system program are inconsistent, at least the receiving array is invoked to execute the backup process. The receiving array is used to store data in random access memory. The backup process is used to temporarily store the first system program in random access memory and then back it up to the second storage partition. The second storage partition is another storage partition in the external flash memory of the ECU. While the backup process is running, it is determined whether there is a download process in the process executed by the receiving array. The download process is used to download the third system program and update the second system program in the first storage partition through the third system program. The third system program is the system program sent by the cloud platform to the ECU. If the download process exists and is running within the processes executed by the receiving array, the backup process is paused until the receiving array finishes executing the download process, at which point the receiving array is invoked to continue executing the backup process.

2. The method according to claim 1, characterized in that, Determining whether the first system program and the second system program are identical includes: Obtain the checksum of the first system program, obtain the checksum of the second system program corresponding to the first system program, the checksum is used to identify the system program version, the checksum includes at least a first checksum and a second checksum, the first checksum is the checksum contained in the first system program, and the second checksum is the checksum contained in the second system program; If the checksum of the first system program is consistent with the checksum of the second system program corresponding to the first system program, the first system program is determined to be consistent with the second system program. If the checksum of the first system program is inconsistent with the checksum of the second system program corresponding to the first system program, the first system program is determined to be inconsistent with the second system program.

3. The method according to claim 2, characterized in that, Before determining whether a download process exists in the process executed by the receiving array, the method further includes: Obtain the first checksum and the third checksum, wherein the third checksum is a checksum contained in the third system program; Obtain the names of the third storage partition and the fourth storage partition, wherein the third storage partition is the storage partition in the built-in flash memory of the ECU requested by the third system program, and the fourth storage partition is the storage partition in the built-in flash memory of the ECU occupied by the first system program; If the first checksum is inconsistent with the third checksum and the name of the third storage partition is consistent with the name of the fourth storage partition, the receiving array is invoked to execute the download process.

4. The method according to claim 1, characterized in that, After the download process is completed in the receiving array, the method further includes: The system detects whether the random access memory has an OTA flashing status variable. The OTA flashing status variable is generated by the random access memory when the flashing operation performed by the download process is normal. The flashing operation is used to update the first system program. If the OTA flashing status variable exists, it is determined that the flashing operation performed by the download process is normal. The Bootloader is then called to retrieve the third system program from the first storage partition and update the first system program based on the third system program. The Bootloader is a bootloader that updates the first system program.

5. The method according to claim 4, characterized in that, After detecting whether the random access memory has an OTA write status variable, the method further includes: If a predetermined condition is met or if the OTA flashing status variable is not detected, the Bootloader is invoked to obtain the fourth system program from the second storage partition and update the third system program according to the fourth system program. The fourth system program is obtained by the backup process from the first system program. The predetermined condition is that an abnormal power outage occurs during the flashing process of the random access memory or the third system program runs abnormally.

6. The method according to any one of claims 1 to 5, characterized in that, Invoking the received array to continue the backup process includes: Obtain the checksum of the first system program, and obtain the checksum of the second system program corresponding to the first system program; If the checksum of the first system program and the checksum of the second system program corresponding to the first system program are inconsistent, the backup process is continued by calling the receiving array.

7. The method according to claim 4, characterized in that, After the download process is completed in the receiving array, the method further includes: Determine if there is an OTA flashing process startup request; If no startup request is received, the backup process continues to execute by calling the receive array; if a startup request exists and the checksum of the first system program is inconsistent with the checksum of the corresponding second system program, the backup process continues to execute by the Bootloader.

8. An OTA backup device, characterized in that, include: The first comparison unit is used to determine whether the first system program and the second system program are consistent. The first system program is the system program running on the EMS, and the second system program is the system program stored in the first storage partition. The first storage partition is a partition in the external flash memory of the ECU. The first processing unit is configured to, in the event that the first system program and the second system program are inconsistent, at least call the receiving array to execute the backup process. The receiving array is configured to store data in random access memory. The backup process is configured to temporarily store the first system program in random access memory and then back it up to a second storage partition. The second storage partition is another partition in the external flash memory of the ECU. The first judgment unit is used to determine whether there is a download process in the process executed by the receiving array when the backup process is running. The download process downloads a third system program and updates the second system program in the first storage partition through the third system program. The third system program is a system program sent by the cloud platform to the ECU. The second processing unit is configured to, when the download process exists in the process executed by the receiving array and the download process is in a running state, pause the backup process until the receiving array finishes executing the download process, and then call the receiving array to continue executing the backup process.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium includes a stored program, wherein, when the program is executed, it controls the device on which the computer-readable storage medium is located to perform the method according to any one of claims 1 to 7.

10. A vehicle, characterized in that, include: An engine, one or more processors, a memory, and one or more programs, wherein the engine includes an ECU and an external flash memory, the ECU being equipped with an EMS and a bootloader, the external flash memory being communicatively connected to the ECU, the one or more programs being stored in the memory and configured to be executed by the one or more processors, the one or more programs including methods for performing any one of claims 1 to 7.

Citation Information

Patent Citations

  • File transmitting method, receiving method and device based on Bluetooth technique

    CN101217295A

  • Method, device and equipment for remotely and automatically downloading file and storage medium

    CN109995869A