OTA firmware upgrading method based on two-wheeled vehicle BMS

Abstract

The invention discloses an OTA firmware upgrading method based on a two-wheeled vehicle BMS, the BMS can judge whether a new firmware version number meets an upgrading condition or not only by means of a URL address downloaded by the new firmware, the new firmware does not need to be downloaded in advance, the whole new firmware can be quickly downloaded to the BMS at a time by adopting a URL downloading mode, and therefore the upgrading efficiency is greatly improved. The invention relates to the technical field of OTA firmware upgrading, in particular to an OTA firmware upgrading method and device. According to the OTA firmware upgrading method based on the two-wheeled vehicle BMS, software and hardware version numbers of the new firmware are placed in the URL based on a URL batch upgrading mode, the BMS can judge whether the version numbers meet upgrading requirements or not, a cloud server does not need to conduct version screening, the possibility of manual operation errors is reduced, and the adaptability of the BMS to a cloud server side is improved.

Description

Technical Field

[0001] The present invention relates to the technical field of OTA firmware upgrade, and in particular to an OTA firmware upgrade method based on a BMS of a two-wheeled vehicle. Background Art

[0002] The Flash distribution description of BMS is provided by Figure 1 As shown in the figure, it shows the partition structure of the Flash storage of the BMS master. Each area is arranged from top to bottom according to the relative address, and the address value increases in sequence. The starting address 0x00000000 of the Bootloader program is a relative address, not the actual storage address in the Flash. The Bootloader program is started when the system is powered on or reset, checks for updates and decides which application area to load (primary partition or backup partition). The user data storage area is used to store user data. For example, the software and hardware version number, upgrade flag, upgrade information, etc. of the current BMS. The App program main partition is the area where the main application is stored. The Bootloader usually loads the application in this area for execution. The App program backup partition is the area where the application backup is stored. If there is a problem with the App main partition during the update or execution process, the system can load the application from this backup partition to ensure.

[0003] The traditional OTA batch upgrade method requires each BMS to interact with the cloud server frequently and with a small amount of data. When the number of BMS devices that need to be upgraded reaches a certain level, it will not only cause huge access pressure on the cloud server, but also increase the probability of OTA upgrade failure. Based on the URL batch upgrade method, the cloud server only needs to store the new firmware on a dedicated storage server. The BMS that needs to be upgraded can obtain the new firmware from the storage server through the URL at one time and quickly. The subsequent upgrade process is executed inside each BMS, which is equivalent to distributing the pressure of the cloud server to each BMS. This distributed upgrade method can greatly reduce the pressure on the cloud server and reduce the possibility of upgrade failure due to data transmission efficiency. Summary of the invention

[0004] 1. Technical issues to be resolved

[0005] In view of the shortcomings of the prior art, the present invention provides an OTA firmware upgrade method based on the BMS of a two-wheeled vehicle. The BMS can determine whether the new firmware version number meets the upgrade conditions only by relying on the URL address of the new firmware download. There is no need to download the new firmware in advance. The present invention adopts the URL download method, which can download the entire new firmware to the BMS in one go and quickly, rather than continuously and gradually obtaining the firmware interactively with the cloud server.

[0006] (II) Technical solution

[0007] To achieve the above objectives, the present invention is implemented through the following technical solutions: an OTA firmware upgrade method based on a two-wheeled vehicle BMS, specifically comprising the following steps:

[0008] S1. Programming preprocessing: BMS connects to the cloud server through the cellular network module. When a new firmware version is available, the server will send an OTA upgrade request to the BMS. The upgrade information of the OTA request only includes the URL address of the new firmware. The cloud server will store the new firmware in the cloud and generate a URL access address. The URL is represented in the form of a string and transmitted to the BMS by the cloud server through JSON packaging. The cloud server will put the software and hardware version number information of the new firmware in its corresponding URL. The specific format of the software and hardware version number is "YYMMDDNN-YYMMDDNN", where the software version number is before the hyphen and the hardware version number is after the hyphen. YY represents the year, MM represents the month, DD represents the date, and NN represents the version number of the day. Using the URL to obtain the new firmware not only simplifies the update process of the BMS hardware side, but also realizes the effective decoupling of the cloud server and the hardware side. In this way, the cloud server can flexibly manage and distribute firmware updates, and the BMS hardware side only needs to download and apply the latest firmware version according to the URL, avoiding complex interaction processes. This method also improves the flexibility and scalability of the system, facilitates subsequent maintenance and function expansion, and then judges the legitimacy of the current BMS status and upgrade information to check whether it meets the pre-programmed conditions. The subsequent programming execution stage is carried out in the Bootloader program. The new firmware upgrade flag and URL need to be written into the Flash to facilitate the Bootloader program to obtain it, and then jump to the Bootloader program to perform the upgrade;

[0009] S2, programming execution;

[0010] S3, programming ends.

[0011] Preferably, checking whether it meets the pre-programmed conditions in step S1 includes:

[0012] A1. Since some or all of the vehicle's functions may be temporarily unavailable during the update, which will affect the user's driving experience, pre-programmed actions are only allowed when the BMS is in idle state;

[0013] A2. The software version in the upgrade information must be higher than the current BMS software version, and the hardware version must be consistent with the current BMS hardware version before the upgrade is allowed. The comparison between the software and hardware version numbers of the current BMS itself and the software and hardware version numbers of the new firmware is to convert the character type "YYMMDDNN" into an integer for size comparison. Compared with comparing the size of the year, month, date, and current version number in sequence, it avoids the trouble of parsing the string and is more convenient and quicker;

[0014] A3. Compared with the traditional OTA upgrade method, the software and hardware version numbers of the new firmware are not stored in the firmware, but in the URL, which means that before downloading the firmware, it is possible to determine whether the new firmware version number meets the upgrade requirements. This not only saves the traffic of the cellular network module, but also reduces the pressure on the cloud server.

[0015] Preferably, in step A1, the BMS being in an idle state means that the BMS has no charging or discharging behavior.

[0016] Preferably, the programming execution of step S2 specifically includes the following steps:

[0017] B1. After entering the Bootloader, read the information in the Flash and check whether there is an upgrade mark. If there is no upgrade mark, jump directly to the App program. If there is an upgrade mark, continue to execute the subsequent content;

[0018] B2. BMS notifies the cellular network module to access the URL through HTTP to download the new firmware. The new firmware will be downloaded directly to the cellular network module at one time and saved persistently in the form of a file. Compared with the traditional OTA method of obtaining new firmware, this method has several advantages: First, the traditional OTA new firmware acquisition method is subject to the memory limitation of the BMS hardware device, and it is impossible to download all the new firmware into the memory at one time. It needs to be upgraded in a download-while-write manner, which will cause the firmware download behavior to continue throughout the upgrade process, increasing the impact of network stability on the upgrade process. The URL download method can download the entire new firmware to the cellular network module at one time and quickly, reducing the high requirements for network stability. Second, when the entire firmware is downloaded to the cellular network module, the subsequent upgrade process is just a wired interaction between the BMS and the cellular network module. Compared with the traditional OTA interaction method with the cloud server with multiple frequencies and small amounts of data, it is not only decoupled from the cloud server, but also the system will be more stable. 3. The new firmware is saved in the cellular network module in a persistent manner. If an unpredictable error occurs during the upgrade process, the new firmware is still saved in the cellular network module, avoiding the need to obtain the firmware from the cloud server again, saving cellular network traffic. 4. When the cellular network module downloads the firmware through the URL, it will automatically perform MD5 verification on the new firmware, calculate the firmware size, etc., and compare it with the MD5 information in the HTTP protocol header to ensure the correctness of the entire firmware and prevent data transmission errors from occurring during the acquisition stage from the cloud server;

[0019] B3. Erase the data in the App backup partition in Flash to prepare for firmware writing;

[0020] B4. The BMS master opens the new firmware stored in the cellular network module, reads a certain number of bytes each time and writes them into the App backup partition, and performs a cumulative CRC32 check on all bytes read each time, until all new firmware is written directly into the backup partition;

[0021] B5. The integrity of the backup partition program is determined by comparing the cumulative number of bytes written with the total size of the new firmware. If the sizes are consistent, the process enters the finalization phase.

[0022] Preferably, the programming finalization of step S3 specifically includes the following steps:

[0023] C1. The last four bytes of the new firmware represent the CRC32 checksum of the entire file. The checksum is compared with the checksum calculated by the BMS master control in step B4 of the programming execution phase to determine the correctness of the backup partition program. If it is not correct, the program rewrites the backup partition or jumps to the main partition program to run according to business needs. Compared with the traditional single App partition structure, this dual App partition structure can effectively prevent the possibility of firmware damage and program failure, reducing after-sales maintenance costs;

[0024] C2. If the result of step C1 is correct, copy the data of the App backup partition to the main partition;

[0025] C3, store the software version number of the new firmware in Flash;

[0026] C4. Jump to the main partition of the App and run it. The upgrade is complete.

[0027] Preferably, judging the correctness of the backup partition program in step C1 is judging the correctness of the new firmware reading process, and forms a double verification judgment with the MD5 verification performed according to the URL firmware download during the programming execution phase.

[0028] (III) Beneficial effects

[0029] The present invention provides an OTA firmware upgrade method based on a two-wheeled vehicle BMS. Compared with the prior art, it has the following beneficial effects:

[0030] (1) In order to prevent repeated upgrades and downgrades of BMS, the OTA firmware upgrade method based on the two-wheeled vehicle BMS often requires the cloud server to determine the upgrade version or place the new firmware version number in the firmware during batch upgrades. In the URL-based batch upgrade method, the software and hardware version numbers of the new firmware are placed in the URL, and the BMS itself can determine whether the version number meets the upgrade requirements. There is no need for the cloud server to perform version screening, which reduces the possibility of manual operation errors and increases the adaptability of the BMS to the cloud server.

[0031] (2) The OTA firmware upgrade method based on the BMS of two-wheeled vehicles, the traditional OTA batch upgrade method requires each BMS to interact with the cloud server frequently and with a small amount of data. When the number of BMS devices that need to be upgraded reaches a certain level, it will not only cause huge access pressure to the cloud server, but also increase the probability of OTA upgrade failure. Based on the URL batch upgrade method, the cloud server only needs to store the new firmware on a dedicated storage server. The BMS that needs to be upgraded can obtain the new firmware from the storage server through the URL at one time and quickly. The subsequent upgrade process is executed inside each BMS, which is equivalent to distributing the pressure of the cloud server to each BMS. This distributed upgrade method can greatly reduce the pressure on the cloud server and reduce the possibility of upgrade failure due to data transmission efficiency. BRIEF DESCRIPTION OF THE DRAWINGS

[0032] Figure 1 This is a Flash distribution diagram of the BMS in the prior art;

[0033] Figure 2 A flowchart for the pre-processing phase of programming for the present invention;

[0034] Figure 3 A flowchart of the programming execution phase of the present invention;

[0035] Figure 4 Flowchart for the finalization phase of programming for the present invention. DETAILED DESCRIPTION

[0036] The following will be combined with the drawings in the embodiments of the present invention to clearly and completely describe the technical solutions in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0037] See also Figure 1-4 The embodiment of the present invention provides a technical solution: an OTA firmware upgrade method based on a two-wheeled vehicle BMS, specifically including the following embodiments:

[0038] Embodiment 1: An OTA firmware upgrade method based on a two-wheeled vehicle BMS specifically comprises the following steps:

[0039] S1. Programming preprocessing: BMS connects to the cloud server through the cellular network module. When a new firmware version is available, the server will send an OTA upgrade request to the BMS. The upgrade information of the OTA request only includes the URL address of the new firmware. The cloud server will store the new firmware in the cloud and generate a URL access address. The URL is represented in the form of a string and transmitted to the BMS by the cloud server through JSON packaging. The cloud server will put the software and hardware version number information of the new firmware in its corresponding URL. The specific format of the software and hardware version number is "YYMMDDNN-YYMMDDNN", where the software version number is before the hyphen and the hardware version number is after the hyphen. YY represents the year, MM represents the month, DD represents the date, and NN represents the version number of the day. Using the URL to obtain the new firmware not only simplifies the update process of the BMS hardware side, but also realizes the effective decoupling of the cloud server and the hardware side. In this way, the cloud server can flexibly manage and distribute firmware updates, and the BMS hardware side only needs to download and apply the latest firmware version according to the URL, avoiding complex interaction processes. This method also improves the flexibility and scalability of the system, facilitates subsequent maintenance and function expansion, and then judges the legitimacy of the current BMS status and upgrade information to check whether it meets the pre-programmed conditions. The subsequent programming execution stage is carried out in the Bootloader program. The new firmware upgrade flag and URL need to be written into the Flash to facilitate the Bootloader program to obtain it, and then jump to the Bootloader program to perform the upgrade;

[0040] S2, programming execution;

[0041] S3, programming ends.

[0042] In the embodiment of the present invention, checking whether the pre-programmed conditions are met in step S1 includes:

[0043] A1. Since some or all of the vehicle's functions may be temporarily unavailable during the update, which will affect the user's driving experience, pre-programmed actions are only allowed when the BMS is in idle state;

[0044] A2. The software version in the upgrade information must be higher than the current BMS software version, and the hardware version must be consistent with the current BMS hardware version before the upgrade is allowed. The comparison between the software and hardware version numbers of the current BMS itself and the software and hardware version numbers of the new firmware is to convert the character type "YYMMDDNN" into an integer for size comparison. Compared with comparing the size of the year, month, date, and current version number in sequence, it avoids the trouble of parsing the string and is more convenient and quicker;

[0045] A3. Compared with the traditional OTA upgrade method, the software and hardware version numbers of the new firmware are not stored in the firmware, but in the URL, which means that before downloading the firmware, it is possible to determine whether the new firmware version number meets the upgrade requirements. This not only saves the traffic of the cellular network module, but also reduces the pressure on the cloud server.

[0046] In the embodiment of the present invention, the BMS being in an idle state in step A1 means that the BMS has no charging or discharging behavior.

[0047] In the embodiment of the present invention, the programming execution of step S2 specifically includes the following steps:

[0048] B1. After entering the Bootloader, read the information in the Flash and check whether there is an upgrade mark. If there is no upgrade mark, jump directly to the App program. If there is an upgrade mark, continue to execute the subsequent content;

[0049] B2. BMS notifies the cellular network module to access the URL through HTTP to download the new firmware. The new firmware will be downloaded directly to the cellular network module at one time and saved persistently in the form of a file. Compared with the traditional OTA method of obtaining new firmware, this method has several advantages: First, the traditional OTA new firmware acquisition method is subject to the memory limitation of the BMS hardware device, and it is impossible to download all the new firmware into the memory at one time. It needs to be upgraded in a download-while-write manner, which will cause the firmware download behavior to continue throughout the upgrade process, increasing the impact of network stability on the upgrade process. The URL download method can download the entire new firmware to the cellular network module at one time and quickly, reducing the high requirements for network stability. Second, when the entire firmware is downloaded to the cellular network module, the subsequent upgrade process is just a wired interaction between the BMS and the cellular network module. Compared with the traditional OTA interaction method with the cloud server with multiple frequencies and small amounts of data, it is not only decoupled from the cloud server, but also the system will be more stable. 3. The new firmware is saved in the cellular network module in a persistent manner. If an unpredictable error occurs during the upgrade process, the new firmware is still saved in the cellular network module, avoiding the need to obtain the firmware from the cloud server again, saving cellular network traffic. 4. When the cellular network module downloads the firmware through the URL, it will automatically perform MD5 verification on the new firmware, calculate the firmware size, etc., and compare it with the MD5 information in the HTTP protocol header to ensure the correctness of the entire firmware and prevent data transmission errors from occurring during the acquisition stage from the cloud server;

[0050] B3. Erase the data in the App backup partition in Flash to prepare for firmware writing;

[0051] B4. The BMS master opens the new firmware stored in the cellular network module, reads a certain number of bytes each time and writes them into the App backup partition, and performs a cumulative CRC32 check on all bytes read each time, until all new firmware is written directly into the backup partition;

[0052] B5. The integrity of the backup partition program is determined by comparing the cumulative number of bytes written with the total size of the new firmware. If the sizes are consistent, the process enters the finalization phase.

[0053] Embodiment 2: The technical solution of the embodiment of the present invention is different from that of embodiment 1 in that the programming end of step S3 specifically includes the following steps:

[0054] C1. The last four bytes of the new firmware represent the CRC32 checksum of the entire file. The checksum is compared with the checksum calculated by the BMS master control in step B4 of the programming execution phase to determine the correctness of the backup partition program. If it is not correct, the program rewrites the backup partition or jumps to the main partition program to run according to business needs. Compared with the traditional single App partition structure, this dual App partition structure can effectively prevent the possibility of firmware damage and program failure, reducing after-sales maintenance costs;

[0055] C2. If the result of step C1 is correct, copy the data of the App backup partition to the main partition;

[0056] C3, store the software version number of the new firmware in Flash;

[0057] C4. Jump to the main partition of the App and run it. The upgrade is complete.

[0058] In the embodiment of the present invention, judging the correctness of the backup partition program in step C1 is judging the correctness of the new firmware reading process, and forms a double verification judgment with the MD5 verification performed according to the URL firmware download during the programming execution phase.

[0059] In summary, in order to prevent repeated upgrades and downgrades of BMS, the present invention often needs to perform upgrade version judgment on the cloud server side or place the new firmware version number in the firmware during batch upgrades. Based on the URL batch upgrade method, the software and hardware version numbers of the new firmware are placed in the URL, and the BMS itself can determine whether the version number meets the upgrade requirements. There is no need for the cloud server to perform version screening, which reduces the possibility of manual operation errors and increases the adaptability of BMS to the cloud server. The traditional OTA batch upgrade method requires each BMS to interact with the cloud server with multiple frequencies and small amounts of data. When the number of BMS devices that need to be upgraded reaches a certain order of magnitude, it will not only cause huge access pressure to the cloud server, but also increase the probability of OTA upgrade failure. Based on the URL batch upgrade method, the cloud server side only needs to store the new firmware in a dedicated storage server. The BMS that needs to be upgraded can obtain the new firmware from the storage server once and quickly through the URL. The subsequent upgrade process is executed inside each BMS, which is equivalent to sharing the pressure of the cloud server to each BMS. This distributed upgrade method can greatly reduce the pressure on the cloud server and reduce the possibility of upgrade failure due to data transmission efficiency.

[0060] Meanwhile, the contents not described in detail in this specification belong to the prior art known to those skilled in the art.

[0061] It should be noted that, in this article, relational terms such as first and second, etc. are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Moreover, the terms "include", "comprise" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or device.

[0062] Although embodiments of the present invention have been shown and described, it will be appreciated by those skilled in the art that various changes, modifications, substitutions and variations may be made to the embodiments without departing from the principles and spirit of the present invention, and that the scope of the present invention is defined by the appended claims and their equivalents.

Claims

1. An OTA firmware upgrade method based on a two-wheeled vehicle BMS, characterized in that: The specific steps include: S1. Programming preprocessing: BMS connects to the cloud server through the cellular network module. When a new firmware version is available, the server will send an OTA upgrade request to the BMS. The upgrade information of the OTA request only includes the URL address of the new firmware. The cloud server will store the new firmware in the cloud and generate a URL access address. The URL is represented in the form of a string and transmitted to the BMS by the cloud server through JSON packaging. The cloud server will put the software and hardware version number information of the new firmware in its corresponding URL. The specific format of the software and hardware version number is "YYMMDDNN-YYMMDDNN". The part before the hyphen indicates the software version number, and the part after the hyphen indicates the hardware version number. YY represents the year, MM represents the month, DD represents the date, and NN represents the version number of the day. Then, the legitimacy of the current BMS status and the upgrade information is judged to check whether it meets the pre-programming conditions. The subsequent programming execution stage is carried out in the Bootloader program. The new firmware upgrade flag and URL need to be written into the Flash to facilitate the Bootloader program to obtain it. Then, it jumps to the Bootloader program to perform the upgrade. S2, programming execution; S3, programming ends.

2. The OTA firmware upgrade method based on the BMS of a two-wheeled vehicle according to claim 1, characterized in that: Checking whether it meets the pre-programmed conditions in step S1 includes: A1. Since some or all of the vehicle's functions may be temporarily unavailable during the update, which will affect the user's driving experience, pre-programmed actions are only allowed when the BMS is in idle state; A2. The software version in the upgrade information must be higher than the current BMS software version, and the hardware version must be consistent with the current BMS hardware version before the upgrade is allowed. The comparison between the software and hardware version numbers of the current BMS itself and the software and hardware version numbers of the new firmware is to convert the character type "YYMMDDNN" into an integer for size comparison; A3. The software and hardware version numbers of the new firmware are not stored in the firmware, but in the URL. This means that you can determine whether the new firmware version number meets the upgrade requirements before downloading the firmware.

3. The OTA firmware upgrade method based on the BMS of a two-wheeled vehicle according to claim 2, characterized in that: In step A1, the BMS being in an idle state means that the BMS has no charging or discharging behavior.

4. The OTA firmware upgrade method based on the BMS of a two-wheeled vehicle according to claim 1, characterized in that: The programming execution of step S2 specifically includes the following steps: B1. After entering the Bootloader, read the information in the Flash and check whether there is an upgrade mark. If there is no upgrade mark, jump directly to the App program. If there is an upgrade mark, continue to execute the subsequent content; B2. BMS notifies the cellular network module to access the URL through HTTP to download the new firmware. The new firmware will be downloaded directly to the cellular network module at one time and saved persistently in the form of a file. B3. Erase the data in the App backup partition in Flash to prepare for firmware writing; B4. The BMS master opens the new firmware stored in the cellular network module, reads a certain number of bytes each time and writes them into the App backup partition, and performs a cumulative CRC32 check on all bytes read each time, until all new firmware is written directly into the backup partition; B5. The integrity of the backup partition program is determined by comparing the cumulative number of bytes written with the total size of the new firmware. If the sizes are consistent, the process enters the finalization phase.

5. The OTA firmware upgrade method based on the BMS of a two-wheeled vehicle according to claim 3, characterized in that: The programming conclusion of step S3 specifically includes the following steps: C1. The last four bytes of the new firmware represent the CRC32 checksum of the entire file, which is compared with the checksum calculated by the BMS master control in step B4 of the programming execution phase to determine the correctness of the backup partition program. If it is not correct, the program re-writes the backup partition or jumps to the main partition program according to business needs; C2. If the result of step C1 is correct, copy the data of the App backup partition to the main partition; C3, store the software version number of the new firmware in Flash; C4. Jump to the main partition of the App and run it. The upgrade is complete.

6. The OTA firmware upgrade method based on the BMS of a two-wheeled vehicle according to claim 4, characterized in that: Judging the correctness of the backup partition program in step C1 is to judge the correctness of the new firmware reading process, which forms a double verification judgment with the MD5 verification performed according to the URL firmware download in the programming execution phase.

Images