A method for online upgrading BMS based on PreBoot and dual BootLoader

Abstract

The application belongs to the technical field of electric vehicle intelligent network connection application, and particularly relates to an online upgrading BMS method based on PreBoot and double BootLoader, which comprises Pflash division, PreBoot and BootLoader0 program making, PreBoot and BootLoader0 burning to the divided area, and running and upgrading. The application proposes a BMS upgrading design scheme of double BootLoader and double application program coexistence, realizes double BootLoader and double application program coexistence through Flash partitioning, can upgrade BootLoader to prevent application program from being tampered by others, can guarantee the safety of BootLoader upgrading through double Bootloader, and will not affect BMS starting and application upgrading in case of upgrading failure, realizes multiple version software coexistence through PFlash division for software backup, can flexibly run different version application programs, and guarantees data validity through Crc check code check.

Description

Technical Field

[0001] This invention belongs to the field of intelligent connected vehicle application technology, and particularly relates to an online upgrade method for BMS based on PreBoot and dual BootLoader. Background Technology

[0002] Over-the-air (OTA) technology is a technique that transmits software, firmware, and operating systems to devices via wireless networks. A Battery Management System (BMS) is an electronic system used to monitor, control, and maintain the performance and status of a battery pack. In electric vehicles and hybrid vehicles, the battery is a crucial energy storage device. In electric vehicles, there is a connection between OTA and the BMS. Electric vehicle manufacturers can use OTA technology to remotely update the vehicle's BMS software to improve battery management strategies, optimize charging algorithms, and update safety features. By updating the BMS via OTA, manufacturers can respond promptly to new battery technology developments and better manage battery performance. This keeps the electric vehicle's battery management system up-to-date, ensuring optimal battery pack performance and lifespan. With OTA, the BMS can be easily and seamlessly updated; maintenance costs can be reduced; and functionality can be improved, optimized, and adapted to new technologies and standards.

[0003] Most OTA updates in existing technologies are implemented by the BootLoader, but the BootLoader cannot perform sub-updates, thus failing to guarantee against the risk of application tampering. Furthermore, the BMS contains only a single copy of the application, which cannot handle BMS system failures if it is compromised. Summary of the Invention

[0004] This invention addresses the technical problems existing in online BMS upgrades by proposing a reasonable, simple, and theoretically sound online BMS upgrade method based on PreBoot and dual BootLoaders. This method enables software backup, suppression of upgrade failures, coexistence of multiple software versions, data verification, and prevention of application tampering.

[0005] To achieve the above objectives, the technical solution adopted by this invention is as follows: an online BMS upgrade method based on PreBoot and dual BootLoaders, comprising the following steps:

[0006] S1. Pflash Division: Pflash is specifically divided into PreBoot, BootLoaderX, and AppX areas. The BootLoaderX area includes BootLoader0 and BootLoader1 areas, and the AppX area includes App0 and App1 areas. BootLoader0 and BootLoader1 areas have a Header area at the top and a BootLoader area at the bottom. App0 and App1 areas have a Header area at the top and an App area at the bottom. The PreBoot area reads the software from the Header area of ​​the BootLoaderX area. Version and availability are considered. The latest available BootLoader is selected for execution. The BootLoaderX area includes a Header area that stores the BootLoader version and availability, and the BootLoader program. The software version and availability are read from the Header area of ​​the AppX area. The latest available version is selected for execution. The BootLoader sub-update and App update are completed. The AppX area contains a Header area that stores the App version and availability. The software restart is triggered through the protocol stack. The Header area stores the software version, availability, and version availability data check code, where availability includes: unknown, valid, and invalid.

[0007] S2. Create the PreBoot and BootLoader0 programs: PreBoot is used to start the latest available BootLoaderX partition. It reads the Header section of BootLoaderX, reads the version and availability, and performs CRC checks on the read data to ensure its validity. If the Header section is invalid, it runs the BootLoader in the BootLoader0 partition; otherwise, it selects the BootLoaderX partition to run. BootLoader0 is used for BootLoader self-upgrade and App upgrade. The upgrade uses the CAN-based CCP / UDS protocol. The BootLoader waits for CAN triggering. When the wait times out, the BootLoader reads the Header section data of the AppX partition and performs CRC checks to select the appropriate partition to jump to. If a BootLoader self-update request is received, it accepts the Bootloader sent by the host computer. The loader version information is set and the availability of the partition is set to unknown. A CRC checksum is generated and written to the Header area. The BootLoader self-updates. After the self-update is completed, the new BootLoaderX is run. The BootLoaderX Header area is read. If the availability is unknown, the unknown is set to invalid. A new checksum is generated and written to the Header area. If the BootLoader is available, the availability is set to valid. A checksum is generated and written to the Header area. If an update is received, the AppX Header area is read. The App version information sent by the host computer is received. The availability is set to unknown and a CRC checksum is generated. If an AppX area with invalid availability exists, the App version information is written to the Header area. The new App is upgraded to this area. After the upgrade is completed, the AppX area is run. Otherwise, the old version of the AppX area is selected, the same upgrade process is performed, and the AppX area is run.

[0008] S3. Write PreBoot and BootLoader0 to the partitioned area: Use the chip's official IDE to configure the Pflash segment, and use the downloader provided by the chip's official website to download the prepared PreBoot and BootLoader0 to the partitioned area via serial port.

[0009] S4. Operation and Upgrade: After powering on and starting the BMS, PreBoot is started first. It reads the Header area in the BootLoaderX area. If BootLoader0 area is selected for operation, and an update request is received, BootLoader1 area is flashed. Otherwise, the reverse is true. After completion, it jumps to verify the availability of BootLoader. If it is available, a suitable App is selected to run. If an App update request is received, an unavailable App partition will be directly flashed to this partition. Otherwise, the App will be upgraded to the old version of the App. Finally, the suitable App is run until restart or power failure ends.

[0010] Preferably, the protocol stack described in step S1 is UDS, XCP, and CCP.

[0011] Preferably, the priority of the Header area availability in step S1 is unknown > valid > invalid. After reading the Header area, the running rule is that if the availability is unknown, the unknown application is run directly; otherwise, the software area with a higher version is selected from the Header area with valid availability. The upgrade priority is invalid > unknown > valid. When there is invalid availability, the invalid application area is selected for upgrade; otherwise, the old version application area is selected for upgrade.

[0012] Preferably, the scenarios that users can choose when performing the upgrade in step S4 include: driver awareness, vehicle parking, battery charging status, low load status, or suitable external temperature.

[0013] Compared with the prior art, the advantages and positive effects of the present invention are as follows:

[0014] This invention proposes a BMS upgrade design scheme with dual Bootloaders and dual applications coexisting. By partitioning the Flash memory, dual Bootloaders and dual applications can coexist. Upgrading the Bootloader can prevent unauthorized modification of the application. Dual Bootloaders ensure the security of Bootloader upgrades. Upgrade failure will not affect the BMS startup or application upgrades. The partitioning of Flash memory backs up the software, enabling multiple software versions to coexist and allowing flexible operation of different application versions. CRC checksum verification ensures the validity of the data. Attached Figure Description

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

[0016] Figure 1 A flowchart illustrating an online BMS upgrade method based on PreBoot and dual BootLoaders, provided as an embodiment of the present invention;

[0017] Figure 2 This is a diagram of the Pflash partitioning structure provided in an embodiment of the present invention;

[0018] Figure 3 The PreBoot, BootLoaderX, and AppX area operation flowcharts provided in this embodiment of the invention;

[0019] Figure 4 The flowchart of the BootLoader and App upgrade process of BMS provided in the embodiments of the present invention. Detailed Implementation

[0020] To better understand the above-mentioned objectives, features, and advantages of the present invention, the present invention will be further described below in conjunction with the accompanying drawings and embodiments. It should be noted that, unless otherwise specified, the embodiments and features described in these embodiments can be combined with each other.

[0021] Numerous specific details are set forth in the following description in order to provide a full understanding of the invention. However, the invention may also be practiced in other ways than those described herein, and therefore the invention is not limited to the specific embodiments disclosed in the following specification.

[0022] Examples, such as Figure 1 As shown, considering that the BootLoader is the core of application software upgrades, directly affecting the upgrade speed and security and determining the upgrade protocol (CAN, USART, and Ethernet, etc.), dual Bootloaders can ensure the security of Bootloader upgrades, preventing BMS startup failures and application upgrades from occurring if upgrades fail. Applications are the core of the BMS and guarantee the stable and safe operation of the battery pack. Dual applications can suppress BMS malfunctions caused by upgrade failures, provide convenience for software version rollback, and enable the coexistence of multiple software versions. To ensure safe BootLoader startup, a PreBoot is added, and the latest BootLoader is available for startup, ensuring the stable operation of the entire BMS system. Therefore, this invention proposes an online BMS upgrade method based on PreBoot and dual BootLoaders. First, Pflash is partitioned, with appropriate allocation based on the chip's Pflash space, such as... Figure 2The Pflash is specifically divided into PreBoot, BootLoaderX, and AppX areas. The BootLoaderX area includes BootLoader0 and BootLoader1 areas, and the AppX area includes App0 and App1 areas. BootLoader0 and BootLoader1 areas have a Header area at the top and a BootLoader at the bottom. App0 and App1 areas have a Header area at the top and an App at the bottom. The PreBoot area reads the software version and availability from the Header area of ​​the BootLoaderX area and selects the latest available BootLoader to run. The BootLoaderX area includes a Header area that stores the BootLoader version and availability, and the BootLoader program. It reads the software version and availability from the Header area of ​​the AppX area and selects the latest available one to run, completing the sub-update of the BootLoader and the update of the App. The AppX area contains a Header area that stores the App version and availability. The software restart is triggered through the protocol stack. The Header area stores the software version, availability, and version availability data check code, where availability includes: unknown, valid, and invalid.

[0023] Specifically, the protocol stack consists of UDS, XCP, and CCP. The priority for running applications in the Header area is unknown > valid > invalid. After reading the Header area, the running rule is that if the availability is unknown, the unknown application is run directly; otherwise, the application with the higher version is selected from the Header area with valid availability. The upgrade priority is invalid > unknown > valid. When there is invalid availability, the invalid application area is selected for upgrade; otherwise, the application area with the older version is selected for upgrade.

[0024] Secondly, create the programs for PreBoot and BootLoader0. The execution flow of PreBoot, BootLoaderX, and AppX areas in Pflash is as follows: Figure 3As shown, PreBoot is used to start the latest available BootLoaderX area, reads the BootLoaderX Header area, reads the version and availability, and performs CRC verification on the read data to ensure the validity of the read data. If the Header area is invalid, the BootLoader in the BootLoader0 area is run; otherwise, the BootLoaderX area is selected for execution. BootLoader0 is used for BootLoader self-upgrade and App upgrade. The upgrade uses the CAN-based CCP / UDS protocol. The BootLoader waits for CAN trigger. When the wait times out, the BootLoader reads the Header area data in the AppX area and performs CRC verification to select the appropriate partition for jump. If a BootLoader self-update request is received, the BootLoader version information sent by the host computer is accepted and the partition is divided. The availability of the region is set to unknown. After generating a CRC checksum, it is written to the Header region and the BootLoader self-updates. After the self-update is completed, the new BootLoaderX is run. The BootLoaderX region's Header region is read. If the availability is unknown, the unknown is set to invalid, a new checksum is generated and written to the Header region. If the BootLoader is available, the availability is set to valid, a checksum is generated and written to the Header region. If an update is received, the AppX region's Header region is read. The App version information sent by the host computer is received. The availability is set to unknown and a CRC checksum is generated. If an AppX region with invalid availability exists, the App version information is written to the Header region, and the new App is upgraded to this region. After the upgrade is completed, the AppX region is run. Otherwise, the old version of the AppX region is selected, the same upgrade process is performed, and the AppX region is run.

[0025] Next, PreBoot and BootLoader0 are programmed into the partitioned area: Pflash segment configuration is performed using the chip's official IDE, and the prepared PreBoot and BootLoader0 are downloaded to the partitioned area via serial port using the programmer provided by the chip's official website.

[0026] Finally, during operation and upgrades, users can choose from scenarios including: driver awareness, vehicle parking, battery charging, low load, or suitable external temperature. After powering on and starting the BMS, PreBoot is first initiated, reading the Header area in the BootLoaderX area. If BootLoader0 is selected for operation, and an update request is received, BootLoader1 is flashed; otherwise, the reverse is true. After completion, it jumps to verify BootLoader availability. If available, a suitable app is selected to run. If an app update request is received, any unavailable app partitions will be directly flashed to that partition; otherwise, the app is upgraded to the older version. Finally, the suitable app is run until a reboot or power failure ends. The specific operation process is as follows: Figure 4 As shown.

[0027] The above description is merely a preferred embodiment of the present invention and is not intended to limit the present invention in any other way. Any person skilled in the art may make changes or modifications to the above-disclosed technical content to create equivalent embodiments for application in other fields. However, any simple modifications, equivalent changes, and modifications made to the above embodiments based on the technical essence of the present invention without departing from the scope of the present invention shall still fall within the protection scope of the present invention.

Claims

1. An online upgrade method for BMS based on PreBoot and dual BootLoaders, characterized in that, Includes the following steps: S1. Pflash Division: Pflash is specifically divided into PreBoot, BootLoaderX, and AppX areas. The BootLoaderX area includes BootLoader0 and BootLoader1 areas, and the AppX area includes App0 and App1 areas. BootLoader0 and BootLoader1 areas have a Header area at the top and a BootLoader area at the bottom. App0 and App1 areas have a Header area at the top and an App area at the bottom. The PreBoot area reads the software from the Header area of ​​the BootLoaderX area. Version and availability: Select the latest available BootLoader to run. The BootLoaderX area includes a Header area that stores the BootLoader version and availability, and the BootLoader program. Read the software version and availability from the Header area of ​​the AppX area, select the latest available one to run, and complete the sub-update of the BootLoader and the update of the App. The AppX area contains a Header area that stores the App version and availability. The software restart is triggered through the protocol stack. The Header area stores the software version, availability, and version availability data check code. Availability includes: unknown, valid, and invalid. S2. Create the PreBoot and BootLoader0 programs: PreBoot is used to start the latest available BootLoaderX area, read the BootLoaderX Header area, read the version and availability, and perform CRC checks on the read data to ensure the validity of the read data. If the Header area is invalid, ... Run the BootLoader from BootLoader0; otherwise, run the BootLoader from BootLoaderX. BootLoader0 is used for BootLoader self-upgrade and App upgrade. The upgrade uses the CAN-based CCP / UDS protocol. The BootLoader waits for CAN to trigger. When the wait times out, the BootLoader reads the Header area data of the AppX partition and performs CRC check to select the appropriate partition to jump to. If a BootLoader self-update request is received, the BootLoader version information sent by the host computer is accepted, and the availability of the partition is set to unknown. A CRC checksum is generated and written to the Header area. The BootLoader self-update is then performed. After the self-update is completed, the new BootLoaderX is run. The Header area of ​​the BootLoaderX area is read. If the availability is unknown, the unknown is set to invalid, and a new checksum is generated and written to the Header area. If the BootLoader is available, the availability is set to valid, and a checksum is generated and written to the Header area. If an update is received, the Header area of ​​the AppX area is read. The App version information sent by the host computer is received, the availability is set to unknown, and a CRC checksum is generated. If an AppX area with invalid availability exists, the App version information is written to the Header area, and the new App is upgraded to this area. After the upgrade is completed, the AppX area is run. Otherwise, the old version of the AppX area is selected, the same upgrade process is performed, and the AppX area is run. S3. Write PreBoot and BootLoader0 to the partitioned area: Use the chip's official IDE to configure the Pflash segment, and use the downloader provided by the chip's official website to download the prepared PreBoot and BootLoader0 to the partitioned area via serial port. S4. Operation and Upgrade: After powering on and starting the BMS, PreBoot is started first. It reads the Header area in the BootLoaderX area. If BootLoader0 area is selected for operation, and an update request is received, BootLoader1 area is flashed. Otherwise, the reverse is true. After completion, it jumps to verify the availability of BootLoader. If it is available, a suitable App is selected to run. If an App update request is received, an unavailable App partition will be directly flashed to this partition. Otherwise, the App will be upgraded to the old version of the App. Finally, the suitable App is run until restart or power failure ends.

2. The online BMS upgrade method based on PreBoot and dual BootLoaders according to claim 1, characterized in that, The protocol stack mentioned in step S1 is UDS, XCP, and CCP.

3. The online BMS upgrade method based on PreBoot and dual BootLoaders according to claim 1, characterized in that, The priority of the Header area availability operation is unknown > valid > invalid. After reading the Header area, the operation rule is that if the availability is unknown, the unknown application is run directly; otherwise, the software area with the higher version is selected from the Header area with valid availability. The upgrade priority is invalid > unknown > valid. When there is invalid availability, the invalid application area is selected for upgrade; otherwise, the old version application area is selected for upgrade.

4. The online BMS upgrade method based on PreBoot and dual BootLoaders according to claim 1, characterized in that, The scenarios that users can choose when performing the upgrade in step S4 include: driver awareness, vehicle parking, battery charging status, low load status, or suitable external temperature.

Images