An upgrade control method for a battery management system and a battery management system

Abstract

The application discloses an upgrading control method for a battery management system, which constructs a hierarchical architecture composed of a total control unit, a master control unit and a plurality of slave control units, and issues an upgrading instruction and upgrading data from the total control unit to trigger an upgrading operation through the master control unit to each slave control unit. In the upgrading process, each unit establishes and updates the upgrading state information representing the upgrading process and stores it in the non-volatile memory; when detecting the system power-on or abnormal restart, the current upgrading process is determined according to the upgrading state information and the continuous execution operation is performed to continue the upgrading from the interruption position. Further, the master control unit acquires the upgrading state information of each slave control unit and performs consistency judgment, generates abnormal state information and feeds back to the upper unit when there is an upgrading abnormality. Through the above-mentioned mode, the hierarchical control, power-off recovery and consistency management of the upgrading process are realized, and the reliability and stability of the system upgrading are improved.

Description

Technical Field

[0001] This invention belongs to the field of battery management technology, and specifically relates to an upgrade control method for a battery management system and a battery management system. Background Technology

[0002] As the scale of electrochemical energy storage systems expands, battery management systems typically adopt a hierarchical architecture consisting of a master control unit and multiple slave control units to achieve distributed monitoring and control of individual battery cells. During system operation, software upgrades are often required at each level of control unit to fix software defects or optimize control strategies.

[0003] In existing technologies, program upgrades mostly employ online upgrade methods based on a single communication link. However, in practical applications, battery management systems often employ multiple communication methods simultaneously. For example, the main control unit may communicate with the host system via Ethernet, while the main control unit may communicate with the slave control units via CAN bus or serial port. Because existing upgrade solutions are mostly designed for a single communication protocol, they struggle to adapt to the differences between various communication protocols. This typically requires designing separate upgrade processes or adjusting the system architecture, resulting in poor system compatibility and high implementation complexity.

[0004] Furthermore, existing program upgrade methods mostly employ a full-package download approach, meaning the entire program is transferred and written to the target device at once. This method lacks an effective progress control mechanism, making it difficult to accurately record the upgrade execution status. If an anomaly occurs during the upgrade process, the entire upgrade process usually needs to be re-executed, resulting in low upgrade efficiency and potentially increasing operational risks in large-scale systems.

[0005] Furthermore, in real-world operating environments, energy storage systems may experience power outages due to grid fluctuations or equipment protection mechanisms. Existing upgrade solutions generally lack power outage recovery mechanisms. When a power outage occurs during the upgrade process, the equipment may remain in an incomplete program state, requiring manual re-triggering of the upgrade. In severe cases, this can even affect the normal operation of the system and reduce system reliability.

[0006] In addition, for battery management systems that contain multiple slave control units, existing technologies usually lack a unified upgrade scheduling mechanism and often adopt an independent upgrade approach for each node, which makes it difficult to achieve multi-node collaborative control, resulting in a long upgrade cycle and low operation and maintenance efficiency. Summary of the Invention

[0007] To address the aforementioned issues, this invention proposes an upgrade control method for battery management systems. By coordinating a cross-protocol layered forwarding mechanism, a packet-based progress control mechanism, and a power outage self-recovery mechanism, a highly reliable program upgrade is achieved in complex communication environments. This solves the problems of poor upgrade adaptability, uncontrollable upgrade process, and easy failure during power outages in existing technologies.

[0008] This invention discloses an upgrade control method for a battery management system, comprising: constructing a hierarchical battery management system architecture consisting of a central control unit, at least one master control unit, and multiple slave control units, wherein the central control unit is communicatively connected to the master control unit, and the master control unit is communicatively connected to the corresponding slave control unit.

[0009] The central control unit sends upgrade instructions and upgrade data to the master control unit, and the master control unit receives and forwards the upgrade data to the corresponding slave control unit to realize the hierarchical upgrade process.

[0010] Upgrade status information for characterizing the current upgrade process is established in at least the master control unit and the slave control unit, and the upgrade status information is stored in the corresponding non-volatile memory.

[0011] When the system is powered on or restarted abnormally, at least the main control unit and the slave control unit determine the current upgrade process based on the upgrade status information and execute the continuation operation corresponding to the upgrade process to continue the upgrade process from the interrupted position.

[0012] During the upgrade process, the master control unit obtains the upgrade status information of each slave control unit it manages, and performs a consistency judgment on the upgrade based on the upgrade status information of each slave control unit. When there is a slave control unit with an abnormal upgrade process, an abnormal status information is generated and fed back to the superior unit.

[0013] According to one embodiment of the present invention, the upgrade status information is implemented by setting a status flag bit in a non-volatile memory, the status flag bit being used to identify the start and end states of the upgrade process.

[0014] According to one embodiment of the present invention, when the system is powered on again, if the status flag indicates that the upgrade is incomplete, the corresponding unit automatically enters the upgrade execution process.

[0015] According to one embodiment of the present invention, the upgrade data is transmitted in a packetized manner and reassembled by the unit receiving the upgrade data in a preset order.

[0016] According to one embodiment of the present invention, during the upgrade data transmission process, each data packet is verified, and if the verification fails, a retransmission or error handling operation is performed.

[0017] According to one embodiment of the present invention, after the upgrade data is written to the target memory, the writing result is verified, and a rewrite operation is performed when the verification is inconsistent.

[0018] According to one embodiment of the present invention, the main control unit and the master control unit, as well as the master control unit and the slave control unit, respectively adopt at least one of Ethernet, serial communication or CAN communication.

[0019] According to one embodiment of the present invention, after receiving upgrade data from the master control unit, the master control unit caches the upgrade data and forwards it to multiple slave control units.

[0020] According to one embodiment of the present invention, the central control unit triggers a batch upgrade process of multiple master control units and their corresponding slave control units through a single upgrade command.

[0021] According to one embodiment of the present invention, during the upgrade process, the master control unit obtains the upgrade status information of each slave control unit it manages, and performs a consistency judgment based on the upgrade status information of each slave control unit. When an abnormal status exists, an abnormality handling mechanism is triggered, and abnormal information is fed back to the superior unit, including:

[0022] After entering the program download mode and completing the upgrade status settings, the slave control unit sends status feedback information to the master control unit. The status feedback information is used to characterize the current upgrade stage or execution status of the slave control unit.

[0023] The master control unit receives status feedback information from each slave control unit and summarizes and processes it. When all slave control units report a normal status, it returns a success message to the master control unit. When there are slave control units that have not received status feedback or whose status is abnormal, it returns an error message to the master control unit.

[0024] A second aspect of this invention discloses a battery management system, comprising: a central control unit, at least one master control unit, and multiple slave control units; wherein the central control unit is communicatively connected to the master control unit, and the master control unit is communicatively connected to a corresponding slave control unit. The central control unit is used to issue upgrade commands and upgrade numbers to the master control unit.

[0025] The master control unit is used to receive the upgrade command and upgrade data, and forward the upgrade data to the corresponding slave control unit to realize the hierarchical distribution of data.

[0026] Both the master control unit and the slave control unit are equipped with non-volatile memory for storing upgrade status information that represents the upgrade process.

[0027] The master control unit and the slave control units are configured to determine the current upgrade process based on the upgrade status information when the system powers on or restarts abnormally, and execute the continuation operation corresponding to the current upgrade process to continue the upgrade process from the interrupted position. The master control unit is also used to obtain the upgrade status information of each slave control unit it manages, and to perform an execution consistency judgment on the upgrade based on the upgrade status information of each slave control unit. When there is a slave control unit with an abnormal upgrade process, it generates abnormal status information and feeds it back to the superior unit.

[0028] According to one embodiment of the present invention, the upgrade data is transmitted in a packetized manner and reassembled by the unit receiving the upgrade data in a preset order.

[0029] According to one embodiment of the present invention, the upgrade status information includes stage identification information for characterizing the upgrade progress.

[0030] According to one embodiment of the present invention, when the master control unit and the slave control unit detect an abnormal system restart or power-on, they read the upgrade status information in the non-volatile memory to perform the continuation operation.

[0031] According to one embodiment of the present invention, the master control unit obtains the upgrade status information of each slave control unit by polling or receiving reports.

[0032] According to one embodiment of the present invention, when the master control unit determines that there is a slave control unit with an abnormal upgrade process, it stops the current upgrade process or performs a retry operation on the abnormal slave control unit.

[0033] According to one embodiment of the present invention, the non-volatile memory is a Flash memory or an EEPROM.

[0034] The technical effects achieved by this invention are as follows: First, by constructing a hierarchical communication link based on different communication protocols between the master control unit and the slave control unit, and by having the master control unit perform protocol conversion on the upgrade data before forwarding it, the upgrade data can be stably transmitted in a heterogeneous communication environment.

[0035] Secondly, by dividing the upgrade program into multiple data packages and establishing an upgrade progress recording mechanism based on these data packages in the slave control unit, each data package has an independent processing status. Compared to existing monolithic program download methods, this application can accurately record the specific location of the program upgrade execution, support upgrade control at the package level, and continue execution only for the incomplete parts in case of anomalies, without repeating the entire upgrade process; thus significantly improving the controllability and execution efficiency of the program upgrade process.

[0036] Furthermore, by setting flags in each unit to indicate the download status, and in conjunction with the upgrade progress recording mechanism, the system can automatically revert to the program download mode and continue the unfinished upgrade process in the event of a power outage or abnormal restart.

[0037] Finally, the master control unit performs unified upgrade scheduling for multiple slave control units and combines the upgrade progress records of each slave control unit to achieve collaborative upgrade control of multiple nodes. Compared with the method of upgrading each device independently, this invention can upgrade the programs of multiple slave control units simultaneously, achieving unified management and status synchronization of the upgrade process, significantly reducing manual intervention and operation and maintenance time, thereby effectively improving program upgrade efficiency and reducing operation and maintenance costs in large-scale energy storage systems. Attached Figure Description

[0038] Figure 1 This is a flowchart of an upgrade control method for a battery management system disclosed in this invention;

[0039] Figure 2 This is a block diagram of a battery management system disclosed in this invention. Detailed Implementation

[0040] Unless otherwise expressly stated, throughout the specification and claims, the term "comprising" or its variations such as "including" or "comprises" shall be understood to include the stated elements or components without excluding other elements or other components.

[0041] The technical solution of the present invention is illustrated below through specific embodiments. It should be understood that the one or more steps mentioned in the present invention do not preclude the existence of other methods and steps before or after the combined steps, or that other methods and steps may be inserted between these explicitly mentioned steps. It should also be understood that these examples are for illustrative purposes only and are not intended to limit the scope of the present invention. Unless otherwise stated, the numbering of each method step is only for the purpose of identifying each method step, and not for limiting the order of each method or limiting the scope of the present invention. Changes or adjustments to their relative relationships, without substantial changes to the technical content, can also be considered as within the scope of the present invention.

[0042] The raw materials and instruments used in the examples are not subject to any specific restrictions on their source; they can be purchased from the market or prepared according to conventional methods known to those skilled in the art.

[0043] This invention discloses an upgrade control method for a battery management system, the overall framework of which is as follows: Figure 1As shown, the battery management system includes: a central control unit, at least one master control unit, and multiple slave control units; wherein the central control unit is communicatively connected to the master control unit, and the master control unit is communicatively connected to its corresponding slave control unit. The central control unit is used to issue upgrade commands and upgrade numbers to the master control unit.

[0044] The master control unit is used to receive the upgrade command and upgrade data, and forward the upgrade data to the corresponding slave control unit to realize the hierarchical distribution of data.

[0045] Both the master control unit and the slave control unit are equipped with non-volatile memory for storing upgrade status information that represents the upgrade process.

[0046] The master control unit and the slave control units are configured to determine the current upgrade process based on the upgrade status information when the system powers on or restarts abnormally, and execute the continuation operation corresponding to the current upgrade process to continue the upgrade process from the interrupted position. The master control unit is also used to obtain the upgrade status information of each slave control unit it manages, and to perform an execution consistency judgment on the upgrade based on the upgrade status information of each slave control unit. When there is a slave control unit with an abnormal upgrade process, it generates abnormal status information and feeds it back to the superior unit.

[0047] The embodiments disclosed in this application illustrate a four-layer architecture. The top layer is a cloud platform or server node. Programs can be remotely uploaded to the cloud platform and then uniformly distributed to the BMS master control unit on the control cabinet of each energy storage container. The BMS master control program can be directly upgraded. For BMS master control upgrades, the BMS master control transmits program packets to the high-voltage box BMS master control unit of each battery cluster via Ethernet using the TCPIP protocol. If a slave control needs to be upgraded, the master control further distributes the program packets and sends them to the slave control via CAN communication. This program distribution process from master control to master control can use Ethernet communication, serial port, CAN, daisy chain, etc., in addition to Ethernet communication, to be compatible with more scenarios. Program distribution can also be done without going through a remote cloud platform; a local debugging computer can be directly connected to the BMS master control, making the operation flexible.

[0048] Specific methods are as follows Figure 2 The method includes: constructing a hierarchical battery management system architecture consisting of a central control unit, at least one master control unit, and multiple slave control units, wherein the central control unit is communicatively connected to the master control unit, and the master control unit is communicatively connected to the corresponding slave control unit.

[0049] The central control unit sends upgrade instructions and upgrade data to the master control unit, and the master control unit receives and forwards the upgrade data to the corresponding slave control unit to realize the hierarchical upgrade process.

[0050] Upgrade status information for characterizing the current upgrade process is established in at least the master control unit and the slave control unit, and the upgrade status information is stored in the corresponding non-volatile memory.

[0051] When the system is powered on or restarted abnormally, at least the main control unit and the slave control unit determine the current upgrade process based on the upgrade status information and execute the continuation operation corresponding to the upgrade process to continue the upgrade process from the interrupted position.

[0052] During the upgrade process, the master control unit obtains the upgrade status information of each slave control unit it manages, and performs a consistency judgment on the upgrade based on the upgrade status information of each slave control unit. When there is a slave control unit with an abnormal upgrade process, an abnormal status information is generated and fed back to the superior unit.

[0053] This invention enables program upgrades at each level of the BMS system architecture, and its detailed implementation method includes the following steps:

[0054] All levels of the BMS system support communication port program download functionality. The BMS system is divided into a three-level architecture: master control (stack level), main control (cluster level), and slave control (PACK level). In this invention, the bootloader program is embedded into the three-level system circuit boards at the factory. The bootloader program supports program download functionality via Ethernet, serial port, CAN, daisy chain, etc. After factory testing, the three-level system is installed in a high-voltage cascaded energy storage container.

[0055] BMS program deployment requires a three-tiered architecture for high-voltage cascaded energy storage BMS program download files, including the master control program download file, the main control program download file, and the slave control program download file. This invention places these three download files in the program file management area of ​​the cloud platform or in the file management area of ​​a local debugging computer.

[0056] The program is downloaded from the cloud platform to the central control. This invention uses the MQTT protocol to connect the BMS central control to the cloud platform. The BMS central control is equipped with a wireless network card and supports 5G network data cards. After the central control establishes a network connection, the downloaded file is transmitted to the central control through the cloud platform via the MQTT protocol. The central control can directly upgrade the program, while the master and slave controls proceed to the following steps.

[0057] Assign BMS addresses to the master controller of each cluster to distinguish its IP address or station address. Use a switch (or a communication method such as CAN bus, 485, daisy chain, etc.) to connect the communication port of the master controller of each cluster, and confirm that the communication connection between each cluster is normal on the host computer of the master controller.

[0058] The detailed steps for downloading the main control program are as follows:

[0059] S501: The main controller sends a command to the BMS master controller to enter the program download mode via Ethernet. The BMS master controller receives the signal and enters the program download mode to wait. It sets the BOOT mode flag to 1 and stores it in the internal FLASH of the master controller chip. In this way, before the program download is successfully completed, it can directly enter the download mode after power-on without sending the command again.

[0060] S502: After the main controller enters the program download mode, it starts the TCPIP server. The master controller connects as a client. After the connection is successful, the master controller first sends a start program download handshake command. After receiving the command, the master controller replies to it. After receiving the reply, the master controller proceeds to the next step. If no reply is received within 10 seconds, an alarm will be triggered indicating that the program download handshake has failed.

[0061] S503: Due to the large size of the program file, the size of a single program transmission is set to 4KB. The master control divides the program file into several segments according to each 4KB packet. The last packet, which is less than 4KB, can be directly packaged. At the end of each packet, a 32-bit checksum is added, which is the sum of the values ​​of the data in this packet. After the program blocks are packaged, they are sent in sequence. After each packet is sent, it is necessary to wait for the master control to reply before sending the next packet. Otherwise, it waits. If no reply is received within 1 minute, an error is reported.

[0062] S504: After receiving the program packet, the main controller first extracts the last 32-bit checksum, then sums all the preceding program bytes, and compares the sum to the checksum. If they are not equal, a data error message is sent to the main controller, thus completing the first verification. If they are equal, the preceding program packets are written sequentially into the chip's APP program FLASH area. After writing, the data written to the FLASH is read out and compared with the program packets sent by the main controller for a second verification. If the verification fails, it is rewritten. If the verification fails twice, an error command is sent to the main controller to report an error. If the verification is successful, a program transmission continuation command is sent to the main controller and the main controller is waited for the program packet to be downloaded.

[0063] S505: Repeat steps S503-S504 until the entire program is downloaded. At this point, the main control sends a program transmission completion command. Upon receiving this command, the main control enters a program jump, transitioning from program download mode to the APP application. After entering the APP application, it compares the version number of this program with the old program version number in the FLASH memory. If the version numbers match, the program needs to be downloaded again; otherwise, the program download is successful. The BOOT mode flag is then set to 0 and stored in the main control chip's internal FLASH memory to prevent re-entry into program download mode upon power-up.

[0064] S506: The main controller supports a timeout exit function in program download mode. If the master control file is not received for a long time, it will jump to the APP program; it also supports a one-click exit mode to prevent accidental operation.

[0065] Compared to master-slave program download, slave-to-master (SWP) downloads involve an additional relay step. The program file needs to be sent from the master controller to the slave controller, which then forwards the data packets frame by frame via CAN communication between the master and slave. Detailed operation is as follows:

[0066] S601: The master controller sends a command to the BMS slave controllers to enter the program download mode via Ethernet. After receiving the command, the master controller shuts down all BMS control, alarm, calculation and other functions to prevent system errors, and sends a CAN message of the command to enter the program download mode to all slave controllers.

[0067] S602: The BMS slave controller receives a signal and enters program download mode to wait. It sets the BOOT mode flag to 1 and stores it in the main control chip's internal FLASH. This way, before the program download is successfully completed, power-on can directly enter download mode without issuing another command. After completing the above operations, it replies to the main control command. The BMS main control only replies to the master control after receiving all slave controller replies. If a timeout occurs or incomplete replies are received, an error command is returned to the master control.

[0068] S603: The master controller sends the program file size to the main controller via Ethernet. After the main controller extracts the information, it sends the program file size to the slave controller via CAN communication. After receiving the program size information, the slave controller sends the received file size back to the master controller. After the master controller receives all the data, it compares the data of each slave controller to ensure that the slave controller data is consistent with the data sent by the master controller. If it does, it proceeds to the next step; otherwise, it reports an error to the master controller and exits.

[0069] S604: Due to the large size of the program file and the need for relaying via the main control APP program, the size of a single program transmission is set to 300 bytes. The main control divides the program file into several segments according to each 300-byte packet. The last packet, which is less than 300 bytes, can be directly packaged. At the end of each packet, a 32-bit checksum is added, which is the sum of the values ​​of the packet. After the program blocks are encapsulated, they are sent in sequence. The main control checks and matches each frame of main control data. If the check fails or no data is received within 1 minute, an error is reported.

[0070] S605: If the verification passes, the master controller will split each packet of central control data it receives into groups of 4 bytes and send it to the slave controller via CAN communication. The CAN communication format is as follows: the first byte is a fixed header 0X00; bytes 2-4 are the CAN communication counter between the master and slave controllers to ensure that the data sent by the master controller is the same as the data received by the slave controller, guaranteeing transmission quality; bytes 5-8 are the data packets; after receiving each CAN data packet sent by the master controller, the slave controller writes the data into its own chip program storage FLASH area in real time.

[0071] S606: The master controller sends the data packets sequentially according to the above format. After sending a total of 300 bytes of data packets, it checks whether the count is correct each time. If it is incorrect, it reports an error to the master controller. If it is correct, it sends a message to the master controller to request the next data packet. This process is repeated until the master controller has sent all the data packets.

[0072] S607: After the master controller sends the program package size, it sends a program download complete command to the main controller, and simultaneously sends a program package size data frame. Upon receiving this, the main controller sends the program download complete command and the program package size data frame to the slave controllers. Each slave controller confirms that the received program size is correct, then returns a program download complete command to the main controller, and the program jumps to the normal APP program. After the main controller receives all slave controller commands, it returns a program completion command to the master controller and enters normal working mode. At this point, the slave controller program download is complete.

[0073] Finally, read all the master and slave version numbers on the main control screen to confirm that the program has been downloaded. If there are individual version numbers that have not changed since the program was downloaded, it indicates that there is a problem with the program writing. In this case, the above method can be used to maintain and upgrade a single master or slave.

[0074] For specific scenarios where the container hatch cannot be opened for maintenance due to excessively high voltage during the commissioning phase of a high-voltage cascaded energy storage system, a combination of remote upgrade and local BMS level 3 display and control upgrade is adopted to solve the maintenance limitations under high-voltage conditions.

[0075] It enables one-click batch upgrades of all BMS master and slave devices within the entire container, and completes the unified issuance and execution of commands through preset control logic.

[0076] It also supports multiple communication methods such as Ethernet, serial port, CAN, and daisy chain for program upgrades, adapting to the transmission needs of different network environments.

[0077] It supports upgrade operations initiated by two types of control terminals: third-level display and control devices (remote and local) and computer host computers, covering a variety of operation and maintenance scenarios.

[0078] After receiving the program file, the BMS master controller forwards the file to the slave controllers and includes a verification function (such as checksum comparison) to ensure the integrity and accuracy of the file transmission.

[0079] It has the ability to recover from sudden power outages during the upgrade process. After restarting, it can automatically detect upgrade interruptions and resume the upgrade without having to re-execute the entire upgrade process.

[0080] The technical effects achieved by this invention are as follows: First, by constructing a hierarchical communication link based on different communication protocols between the master control unit and the slave control unit, and by having the master control unit perform protocol conversion on the upgrade data before forwarding it, the upgrade data can be stably transmitted in a heterogeneous communication environment.

[0081] Compared with existing upgrade methods that only support a single communication protocol, this application does not require modification of the original device communication structure and can be compatible with multiple communication methods such as Ethernet, CAN bus, serial port or daisy chain. This improves the system's adaptability to complex field environments, reduces system modification costs, and enhances the deployment flexibility of the battery management system in different energy storage scenarios.

[0082] Secondly, by dividing the upgrade program into multiple data packages and establishing an upgrade progress recording mechanism based on these data packages in the slave control unit, each data package has an independent processing status. Compared to existing monolithic program download methods, this application can accurately record the specific location of the program upgrade execution, support upgrade control at the package level, and continue execution only for the incomplete parts in case of anomalies, without repeating the entire upgrade process; thus significantly improving the controllability and execution efficiency of the program upgrade process.

[0083] Furthermore, by setting flags in each unit to indicate the download status, and in conjunction with the upgrade progress recording mechanism, the system can automatically revert to the program download mode and continue the unfinished upgrade process in the event of a power outage or abnormal restart.

[0084] Compared to existing technologies where power outages require restarting the upgrade process or may lead to system malfunctions, this application can automatically identify the upgrade status and resume the upgrade process, avoiding duplicate data transmission, improving upgrade efficiency, and preventing program corruption or system failure due to upgrade interruptions. This significantly enhances the stability and reliability of the battery management system in complex operating environments.

[0085] Finally, the master control unit performs unified upgrade scheduling for multiple slave control units and combines the upgrade progress records of each slave control unit to achieve collaborative upgrade control of multiple nodes. Compared with the method of upgrading each device independently, this invention can upgrade the programs of multiple slave control units simultaneously, achieving unified management and status synchronization of the upgrade process, significantly reducing manual intervention and operation and maintenance time, thereby effectively improving program upgrade efficiency and reducing operation and maintenance costs in large-scale energy storage systems.

[0086] The foregoing description of specific exemplary embodiments of the invention is for illustrative and explanatory purposes. These descriptions are not intended to limit the invention to the precise forms disclosed, and it will be apparent that many changes and variations can be made in accordance with the foregoing teachings. The exemplary embodiments were chosen and described in order to explain the specific principles of the invention and its practical application, thereby enabling those skilled in the art to implement and utilize various different exemplary embodiments of the invention, as well as various different choices and variations. The scope of the invention is intended to be defined by the claims and their equivalents.

Claims

1. An upgrade control method for a battery management system, characterized in that, include: A hierarchical battery management system architecture is constructed, consisting of a central control unit, at least one master control unit, and multiple slave control units. The central control unit is communicatively connected to the master control unit, and the master control unit is communicatively connected to the corresponding slave control unit. The central control unit sends upgrade instructions and upgrade data to the master control unit, and the master control unit receives and forwards the upgrade data to the corresponding slave control unit to realize the hierarchical upgrade process. During the upgrade process, upgrade status information for characterizing the current upgrade process is established and updated in at least the master control unit and the slave control unit, and the upgrade status information is stored in the corresponding non-volatile memory. When a system power-on or abnormal restart is detected, at least the main control unit and the slave control unit determine the current upgrade process based on the upgrade status information, and control the execution of the continuation operation corresponding to the upgrade process, so as to continue the upgrade process from the interruption point. During the upgrade process, the master control unit obtains the upgrade status information of each slave control unit it manages, and performs a consistency judgment on the upgrade based on the upgrade status information of each slave control unit. When there is a slave control unit with an abnormal upgrade process, an abnormal status information is generated and fed back to the superior unit.

2. The method according to claim 1, characterized in that, The upgrade status information is implemented by setting a status flag bit in non-volatile memory. The status flag bit is used to identify the start and end status of the upgrade process.

3. The method according to claim 2, characterized in that, When the system is powered on again, if the status flag indicates that the upgrade is incomplete, the corresponding unit will automatically enter the upgrade execution process.

4. The method according to claim 1, characterized in that, The upgrade data is transmitted in packets and reassembled by the receiving unit in a preset order.

5. The method according to claim 4, characterized in that, During the upgrade data transmission process, each data packet is verified, and if the verification fails, a retransmission or error handling operation is performed.

6. The method according to claim 1, characterized in that, After the upgrade data is written to the target memory, the writing result is verified. If the verification is inconsistent, a rewrite operation is performed.

7. The method according to claim 1, characterized in that, The communication between the central control unit and the master control unit, and between the master control unit and the slave control unit, adopts at least one of the following communication methods: Ethernet, serial communication, or CAN communication.

8. The method according to claim 1, characterized in that, After receiving upgrade data from the central control unit, the master control unit caches the upgrade data and forwards it to multiple slave control units.

9. The method according to claim 1, characterized in that, The central control unit triggers a batch upgrade process for multiple master control units and their corresponding slave control units through a single upgrade command.

10. The method according to claim 1, characterized in that, During the upgrade process, the master control unit acquires the upgrade status information of each slave control unit it manages, and performs a consistency judgment based on the upgrade status information of each slave control unit. When an abnormal status exists, an exception handling mechanism is triggered, and the exception information is fed back to the superior unit, including: After entering the program download mode and completing the upgrade status settings, the slave control unit sends status feedback information to the master control unit. The status feedback information is used to characterize the current upgrade stage or execution status of the slave control unit. The master control unit receives status feedback information from each slave control unit and summarizes and processes it. When all slave control units report a normal status, it returns a success message to the master control unit. When there are slave control units that have not received status feedback or whose status is abnormal, it returns an error message to the master control unit.

11. A battery management system, characterized in that, The battery management system includes: a central control unit, at least one master control unit, and multiple slave control units; wherein the central control unit is communicatively connected to the master control unit, and the master control unit is communicatively connected to the corresponding slave control unit; The central control unit is used to issue upgrade instructions and upgrade numbers to the main control unit; The master control unit is used to receive the upgrade command and upgrade data, and forward the upgrade data to the corresponding slave control unit to realize the hierarchical distribution of data; Both the master control unit and the slave control unit are equipped with non-volatile memory for storing upgrade status information representing the upgrade process; The master control unit and the slave control unit are configured to determine the current upgrade process based on the upgrade status information when the system is powered on or restarted abnormally, and to execute the continuation operation corresponding to the current upgrade process so as to continue the upgrade process from the interruption point. The master control unit is also used to obtain the upgrade status information of each slave control unit it manages, and to perform consistency judgment on the upgrade based on the upgrade status information of each slave control unit. When there is a slave control unit with an abnormal upgrade process, abnormal status information is generated and fed back to the superior unit.

12. The battery management system according to claim 11, characterized in that, The upgrade data is transmitted in packets and reassembled by the receiving unit in a preset order.

13. The battery management system according to claim 11, characterized in that, The upgrade status information includes stage identifier information used to characterize the upgrade progress.

14. The battery management system according to claim 11, characterized in that, When the master control unit and the slave control unit detect an abnormal system restart or power-on, they read the upgrade status information in the non-volatile memory to execute the continuation operation.

15. The battery management system according to claim 11, characterized in that, The master control unit obtains the upgrade status information of each slave control unit by polling or receiving reports.

16. The battery management system according to claim 11, characterized in that, When the master control unit determines that there is a slave control unit with an abnormal upgrade process, it stops the current upgrade process or performs a retry operation on the abnormal slave control unit.

17. The battery management system according to claim 11, characterized in that, The non-volatile memory is either Flash memory or EEPROM.

Images