Upgrading method, device, system and medium

Abstract

The invention relates to the technical field of energy storage, and discloses an upgrading method, device and system and a medium, the upgrading method, device and system are applied to an energy storage product, the energy storage product is formed by connecting multiple BMS devices in parallel, each BMS device corresponds to a battery pack, the multiple BMS devices comprise a master device and at least one slave device, and the method comprises the steps that upgrading firmware information is obtained; detecting whether the multiple BMS devices meet a device upgrading condition or not; and if the equipment upgrading condition is met, controlling the master equipment to analyze the upgrading firmware information, and carrying out file transmission upgrading on each slave equipment based on an analysis result so as to realize upgrading of the corresponding battery pack of each slave equipment. The battery pack in the energy storage product is effectively upgraded, the product upgrading cost can be saved, the upgrading operation process is simplified, the battery upgrading speed is increased, the success rate of remote upgrading is greatly increased, and the use experience of a user is met.

Description

Technical Field

[0001] The present invention relates to the field of energy storage technology, and in particular to an upgrading method, device, system and medium. Background Art

[0002] In the field of energy storage technology, an energy storage system is a system that connects multiple battery packs in parallel to facilitate power supply to the load. It includes various types, such as power storage, household storage, industrial and commercial storage, etc. For various energy storage systems, a battery management system (BMS) is often used to provide data collection, status monitoring and control for each battery pack to ensure safe and reliable operation of the system.

[0003] At present, the batteries in the home energy storage system cannot be upgraded internally. Therefore, a communication control box, namely a telematics box (TBOX), is required in rack-mounted energy storage products. A WIFI module is mounted on the TBOX to connect to the server to download the upgrade file. The TBOX communicates with the BMS device through CAN (Controller Area Network). The TBOX is the host and all BMS devices are slaves that receive the file to complete the transmission of the upgrade file. In wall-mounted energy storage products, a data collector must be mounted on each battery. Different battery packs need to be distinguished on the server through the SN of the battery pack, and then each battery pack is remotely upgraded separately in turn, which is slow and prone to omissions. Summary of the invention

[0004] In view of this, the present invention provides an upgrade method, device, system and medium to solve the problems in the existing energy storage products mentioned in the above technical background, such as high upgrade cost, complicated process, difficulty in achieving effective upgrade of battery packs, and affecting user experience.

[0005] In a first aspect, the present invention provides an upgrade method, which is applied to an energy storage product. The energy storage product is composed of multiple BMS devices connected in parallel, each BMS device corresponds to a battery pack, and the multiple BMS devices include a master device and at least one slave device. The method includes:

[0006] Get the firmware upgrade information;

[0007] Check whether multiple BMS devices meet the equipment upgrade conditions;

[0008] If the device upgrade conditions are met, the master device is controlled to parse the upgrade firmware information, and based on the parsing results, the files are transferred and upgraded to each slave device to achieve the upgrade of the corresponding battery pack of each slave device.

[0009] The present invention aims at upgrading the battery pack inside an energy storage product composed of multiple BMS devices connected in parallel. It detects whether the multiple BMS devices meet the device upgrade conditions, and controls the master device to implement file transfer upgrade of each slave device based on the upgrade firmware information when the conditions are met, thereby completing the upgrade of the corresponding battery pack of each slave device. This not only simplifies the upgrade operation process, increases the battery upgrade speed, and saves product upgrade costs, but also greatly improves the efficiency and success rate of the battery pack upgrade, satisfying the user experience.

[0010] In an optional implementation, detecting whether a plurality of BMS devices meet the device upgrade condition includes:

[0011] Acquire first status data of the master device;

[0012] When the first state data meets the preset upgrade condition, detecting whether there is a slave device in a working state;

[0013] If there is at least one slave device in a working state, the second state data corresponding to each slave device in a working state is obtained respectively, and it is determined whether each second state data satisfies a preset upgrade condition;

[0014] Determine a device self-test result based on all the second status data, where the device self-test result includes pass or fail;

[0015] If the device self-test result is passed, it is determined that the device upgrade conditions are met;

[0016] If the device self-test result is failed, it is determined that the device upgrade conditions are not met.

[0017] When the first status data corresponding to the master device meets the preset upgrade conditions, that is, when the device self-test of the master device passes, the present invention detects and obtains the corresponding status data of each slave device currently running, and determines the final device self-test result based on it, and then determines whether multiple BMS devices meet the device upgrade conditions based on the device self-test result. This not only ensures the accuracy of device self-test and improves the upgrade success rate, but also greatly simplifies the upgrade process.

[0018] In an optional implementation, determining a device self-test result based on all the second state data includes:

[0019] Determine whether each second state data satisfies a preset upgrade condition;

[0020] If at least one of the second status data does not satisfy the preset upgrade condition, determining that the device self-test result is failed;

[0021] If all the second status data meet the preset upgrade conditions, it is determined that the device self-test result is passed.

[0022] The present invention fully considers the operating status of each BMS device and battery pack before upgrading, and determines the device self-test result by judging whether the operating data of each BMS device and its corresponding battery pack meets the preset upgrade conditions, which can greatly improve the accuracy of the device self-test result and thus ensure the success rate of subsequent battery pack upgrades.

[0023] In an optional implementation, after determining that the device self-test result is failed, the upgrade method further includes:

[0024] After a first preset time, return to the step of obtaining the first status data of the master device, or obtaining the first status data of the master device and the second status data corresponding to each slave device, and count the cumulative number of times the device self-test result fails;

[0025] If the accumulated number of times exceeds the preset number threshold, the device self-test result is finally determined to be failed.

[0026] The present invention designs multiple equipment self-test processes, and determines the final self-test result by judging the cumulative number of times the equipment self-test results fail and the size of the corresponding threshold, which can eliminate occasional errors of failure and thus improve the accuracy of the equipment self-test results.

[0027] In an optional implementation, the main device communicates with the server through a data collector to obtain the upgrade firmware information, including:

[0028] In response to receiving an upgrade request generated when a user starts an upgrade through a mobile phone APP or server settings, the control main device obtains upgrade firmware information from the server through a data collector and stores the upgrade firmware information locally.

[0029] In order to respond to the user's upgrade request, the present invention only obtains the corresponding upgrade firmware information by designing a data collector corresponding to the main control device, which can save the number of data collectors used, help reduce the upgrade cost, and enhance the user experience.

[0030] In an optional implementation, before the upgraded firmware information is locally stored, the upgrading method further includes:

[0031] Verify the upgrade firmware information;

[0032] If the verification fails, return to the step of obtaining the upgrade firmware information;

[0033] If the verification is successful, the step of locally storing the upgraded firmware information is performed.

[0034] The present invention takes into account the validity verification of the upgraded firmware information and designs a verification process for the upgraded firmware information to ensure the authenticity and validity of the upgraded firmware information, thereby improving the success rate of subsequent battery pack upgrades.

[0035] In an optional implementation, controlling the master device to parse the upgrade firmware information, and performing file transfer upgrade on each slave device based on the parsing result, so as to implement the upgrade of the corresponding battery pack of each slave device, including:

[0036] Control the master device to read the upgrade firmware information from the local storage, parse it to obtain the target upgrade file, and send the upgrade start instruction to each slave device;

[0037] In response to the received upgrade response results of each slave device, the target upgrade file is transmitted to each slave device in segments, so that each slave device is upgraded based on the received target upgrade file, and an upgrade result is generated, wherein the upgrade result includes upgrade success and upgrade failure;

[0038] Receive upgrade results fed back by each slave device;

[0039] If the upgrade result is successful, restart the energy storage product to complete the upgrade of the corresponding battery pack of each slave device;

[0040] If the upgrade result is an upgrade failure, the reason for the upgrade failure is recorded, and the step of sending the upgrade start command to each slave device is returned to count the cumulative number of failures corresponding to the upgrade failure; when the cumulative number of failures exceeds the failure number threshold, the current upgrade is terminated and the corresponding upgrade failure reason is reported to the server.

[0041] The present invention can realize effective firmware upgrade of all slave devices through the file transmission upgrade process of the master device to each slave device, which not only speeds up the upgrade operation process and saves the upgrade cost, but also improves the success rate of remote upgrade.

[0042] In a second aspect, the present invention provides an upgrade device, which is applied to an energy storage product. The energy storage product is composed of multiple BMS devices connected in parallel, each BMS device corresponds to a battery pack, and the multiple BMS devices include a master device and at least one slave device. The device includes:

[0043] An acquisition module is used to obtain upgrade firmware information;

[0044] A detection module is used to detect whether multiple BMS devices meet the equipment upgrade conditions;

[0045] The upgrade module is used to control the master device to parse the upgrade firmware information if the device upgrade conditions are met, and to perform file transfer upgrade on each slave device based on the analysis results to achieve the upgrade of the corresponding battery pack of each slave device.

[0046] The upgrade device of the present invention enables the master device to upgrade the firmware of all slave devices by means of file transfer, thereby completing the effective upgrade of the internal battery pack of the energy storage product. It has the significant advantages of low product upgrade cost, simple upgrade operation process, fast battery upgrade speed, and high remote upgrade success rate, which greatly satisfies the user experience.

[0047] In a third aspect, the present invention provides a system, the system includes a server, a data collector and an energy storage product, the energy storage product is composed of multiple BMS devices in parallel, each BMS device corresponds to a battery pack, the multiple BMS devices include a master device and at least one slave device, the master device is communicatively connected to the server through the data collector; the energy storage product also includes a controller, wherein the controller includes a memory and a processor, the memory and the processor are communicatively connected to each other, computer instructions are stored in the memory, and the processor executes the computer instructions to execute an upgrade method of the above-mentioned first aspect or any corresponding embodiment thereof.

[0048] In a fourth aspect, the present invention provides a computer-readable storage medium having computer instructions stored thereon, the computer instructions being used to enable a computer to execute an upgrade method according to the first aspect or any corresponding embodiment thereof. BRIEF DESCRIPTION OF THE DRAWINGS

[0049] In order to more clearly illustrate the specific implementation methods of the present invention or the technical solutions in the prior art, the drawings required for use in the specific implementation methods or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are some implementation methods of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative work.

[0050] Figure 1 is a flowchart of an upgrading method according to an embodiment of the present invention;

[0051] Figure 2 is a flowchart of another upgrading method according to an embodiment of the present invention;

[0052] Figure 3 It is a structural schematic diagram of a multi-battery pack parallel system;

[0053] Figure 4 is to obtain the upgrade firmware schematic;

[0054] Figure 5 It is a schematic diagram of the saved firmware upgrade information;

[0055] Figure 6 It is a flowchart of the upgrade preparation;

[0056] Figure 7 It is a schematic diagram of the various stages of file transfer;

[0057] Figure 8 This is a schematic diagram of file transfer from the host to the slave;

[0058] Fig. 9 It is a flowchart of the upgrade;

[0059] Fig.10 is a structural block diagram of an upgrading device according to an embodiment of the present invention;

[0060] Fig.11 Schematic diagram of the structure of the controller of the system according to the embodiment of the present invention. DETAILED DESCRIPTION

[0061] In order to make the purpose, technical solution and advantages of the embodiments of the present invention clearer, the technical solution in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are 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 those skilled in the art without creative work are within the scope of protection of the present invention.

[0062] An embodiment of the present invention provides an upgrade method embodiment. It should be noted that the steps shown in the flowchart of the accompanying drawings can be executed in a computer system such as a set of computer executable instructions, and although a logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in an order different from that shown here.

[0063] In this embodiment, an upgrade method is provided, which is applied to an energy storage product. The energy storage product is composed of multiple BMS devices connected in parallel. Each BMS device corresponds to a battery pack. The multiple BMS devices include a master device and at least one slave device. Figure 1 is a flowchart of an upgrade method according to an embodiment of the present invention. Figure 1 As shown, the process includes the following steps:

[0064] Step S101, obtaining upgrade firmware information.

[0065] It should be noted that the specific content and acquisition process of the firmware upgrade information in this embodiment are not limited here, and are adaptively adjusted based on actual needs. For example, for a certain model of home storage product containing multiple parallel battery packs, where each battery pack corresponds to a BMS device, the master device (also called the master BMS or host) and slave device (also called the slave BMS or slave machine) of the multiple BMS devices in the home storage product can be automatically identified through wiring, and the master BMS communication ID node number is set to 0, and the software automatically addresses other slave machines with different ID nodes. Specifically, after the user initiates an upgrade request for the home storage product, the master BMS mounted data acquisition module can connect to the server via WIFI to obtain the firmware information required for the current upgrade, which is only an exemplary description.

[0066] Step S102, detecting whether a plurality of BMS devices meet device upgrade conditions.

[0067] It should be noted that the specific content of the equipment upgrade conditions in this embodiment can be adaptively adjusted based on actual needs, such as whether there is any abnormality in the state of the BMS device itself, including the abnormality judgment of the voltage, temperature, current, etc. of each string of battery cells in its corresponding battery pack, which is only for exemplary description.

[0068] Step S103, if the device upgrade condition is met, the master device is controlled to parse the upgrade firmware information, and based on the parsing result, the file transfer upgrade is performed on each slave device to achieve the upgrade of the corresponding battery pack of each slave device.

[0069] The upgrade method of the embodiment of the present invention is aimed at upgrading the battery pack inside the energy storage product composed of multiple BMS devices in parallel. It detects whether the multiple BMS devices meet the device upgrade conditions, and controls the master device to realize the file transfer upgrade of each slave device based on the upgrade firmware information when the conditions are met, thereby completing the upgrade of the corresponding battery pack of each slave device. This not only simplifies the upgrade operation process, improves the battery upgrade speed, and saves the product upgrade cost, but also greatly improves the efficiency and success rate of the battery pack upgrade, satisfying the user experience.

[0070] In this embodiment, an upgrade method is provided, which is applied to an energy storage product. The energy storage product is composed of multiple BMS devices connected in parallel. Each BMS device corresponds to a battery pack. The multiple BMS devices include a master device and at least one slave device. Figure 2 is a flow chart of another upgrading method according to an embodiment of the present invention. Figure 2 As shown, the process includes the following steps:

[0071] Step S201, obtaining firmware upgrade information.

[0072] In this embodiment, the main device is connected to the server through a data collector, and the specific communication method is adaptively adjusted based on actual needs, such as through WIFI. Specifically, the above step S201 includes:

[0073] Step S2011, in response to receiving an upgrade request generated when a user starts an upgrade through a mobile phone APP or server settings, the main device is controlled to obtain upgrade firmware information from the server through a data collector, and the upgrade firmware information is stored locally.

[0074] In this embodiment, when the upgraded firmware information is stored locally, it can be stored in a memory carried by the main device, such as a FLASH memory of a non-volatile memory, and the corresponding storage address space is named for the upgraded firmware information, such as APP3, which is only used as an example.

[0075] In order to respond to user upgrade requests, the embodiment of the present invention only obtains corresponding upgrade firmware information by designing a data collector corresponding to the main control device, which can save the number of data collectors used, help reduce upgrade costs, and enhance user experience.

[0076] In actual applications, after the data collector downloads the upgrade firmware from the server to the main BMS device, a file verification is required before storage to ensure the validity of the stored upgrade firmware information. Specifically, in the above step S2011, before the upgrade firmware information is locally stored, the upgrade method of this embodiment also includes:

[0077] Step A1, verifying the upgrade firmware information.

[0078] It should be noted that the verification process in this embodiment is not limited here, and is adaptively adjusted based on actual application requirements and the communication protocol type of file transfer. For example, after the data collector obtains the upgraded firmware information, it uses the RS485 hardware interface and the Xmode-1K file transfer protocol to send the upgraded firmware information to the main device; considering the transmission characteristics of the Xmode-1K protocol, the corresponding design of the transmission process segment verification and the full firmware verification after the transmission are completed are only used as an exemplary description.

[0079] It should be noted that segment verification is a data verification method used to ensure the integrity and accuracy of data. It specifically verifies specific parts of the data (such as a segment) to ensure that these parts have not been tampered with; firmware verification involves a series of verifications on the firmware file to ensure that it has not been tampered with or damaged, including but not limited to checksum calculations, where the firmware file is calculated using a specific algorithm to obtain a checksum value, and then during the firmware upgrade process, this value is calculated again and compared with the original checksum value to ensure that the two are consistent, which helps to ensure the reliability and security of the firmware upgrade process.

[0080] Step A2: If the verification fails, return to the step of obtaining the upgrade firmware information.

[0081] Step A3: If the verification is successful, the step of locally storing the upgraded firmware information is executed.

[0082] In the embodiment of the present invention, the validity verification of the upgraded firmware information is taken into consideration. By designing a verification process for the upgraded firmware information, the authenticity and validity of the upgraded firmware information can be ensured, thereby improving the success rate of subsequent battery pack upgrades.

[0083] Step S202, detecting whether a plurality of BMS devices meet device upgrade conditions.

[0084] In this embodiment, this step mainly performs self-check on all BMS devices, that is, obtains the status data corresponding to each device to determine whether the device upgrade conditions are met. Since the master device is responsible for receiving the upgrade information of the server and controlling the upgrade of itself and each slave device, this embodiment designs a device status data acquisition and self-check method of first obtaining the master device status data, and then determining whether to detect the slave device status data according to the master device status data. The above step S202 includes:

[0085] Step 1: Obtain first status data of the master device.

[0086] In this embodiment, the specific method for obtaining the first state data is not limited here, and is obtained based on the conventional method of obtaining in the field. For example, the host device can sample and monitor the voltage, temperature, and current of each string of cells in the battery pack through the internally integrated AFE (Active Front End) front-end analog chip to obtain the corresponding state data, which is only an exemplary description.

[0087] Step 2: When the first status data meets the preset upgrade condition, detect whether there is a slave device in working state.

[0088] It should be noted that, in this embodiment, if the first status data does not meet the preset upgrade condition, it is considered that the device self-test result has failed, and the device self-test process is terminated, which can reduce the amount of status data obtained and help speed up the upgrade process.

[0089] In this embodiment, whether to detect the slave device status data is determined by judging whether the first status data satisfies the preset upgrade conditions, wherein the specific content of the preset upgrade conditions can be adaptively adjusted based on actual needs, such as the preset upgrade conditions including that the battery voltage is not in an undervoltage state, the communication is normal, there is no conflict between the battery and device coding, and the device working state is not in charging or discharging.

[0090] In a specific embodiment, the main BMS will periodically read the battery cell voltage through the AFE. If it is detected that the battery cell voltage is lower than the parameter setting value of the undervoltage protection voltage at normal temperature (i.e. 0-25°C), the corresponding BMS device will generate an undervoltage protection fault. Since the battery pack will automatically shut down after the undervoltage protection occurs, the upgrade will not be performed after this fault is detected in the upgrade preparation stage, that is, the device self-test is considered to have passed. After the battery pack is charged and the undervoltage protection is restored, it is necessary to re-check whether other conditions allow the upgrade.

[0091] In this embodiment, since all parallel battery packs are mounted on the same CAN bus, the master BMS performs disconnection timeout detection on the slave battery pack by acquiring the heartbeat frames of other battery packs, and updates the current number of online battery packs in real time. If the number of online battery packs is 0, it is determined that there are currently no parallel slaves, that is, the slave device is not in working condition and only needs to upgrade itself, that is, the master BMS parses the firmware upgrade information and then performs its own firmware upgrade.

[0092] Step 3: If there is at least one slave device in working state, the second state data corresponding to each slave device in working state is obtained respectively, and it is determined whether each second state data meets the preset upgrade condition.

[0093] In this embodiment, the specific method for acquiring the second status data is based on the conventional acquisition method in the field, such as the master device communicates with all slave devices through the CAN BUS serial communication bus, and performs timeout disconnection detection and ID node conflict detection on the communication data of each slave device to obtain the corresponding status data.

[0094] Step 4: Determine a device self-test result based on all the second status data, where the device self-test result includes pass and fail.

[0095] In this embodiment, determining the device self-test result based on all the second state data in the above step 4 includes:

[0096] Step B1, respectively determining whether each second status data satisfies a preset upgrade condition.

[0097] It should be noted that if there is a slave BMS in parallel with the master BMS and in working state, in this embodiment, the BMS device also needs to perform self-inspection to ensure that its current state is suitable for upgrading; if there are multiple slave BMSs, each BMS device needs to perform self-inspection to ensure that the current state of all BMS devices has met the subsequent upgrade.

[0098] Step B2: If there is at least one second status data that does not meet the preset upgrade condition, determine that the device self-test result is failed.

[0099] In actual applications, there is a possibility of BMS equipment self-test errors. In this embodiment, multiple equipment self-test processes are designed to eliminate occasional errors in which the equipment self-test results fail, thereby improving the accuracy of the equipment self-test results. Specifically, after determining that the equipment self-test result fails, the upgrade method of this embodiment also includes:

[0100] Step B21, after the first preset time, returns to the step of obtaining the first status data of the master device, or obtaining the first status data of the master device and the second status data corresponding to each slave device, and counts the cumulative number of times the device self-test result fails.

[0101] In this embodiment, the specific value of the first preset time is not limited here, and is adaptively adjusted based on actual needs. For example, the first preset time is 10 minutes, which is only used as an exemplary description.

[0102] Step B22: If the accumulated number of times exceeds the preset number threshold, it is finally determined that the device self-test result is failed.

[0103] In this embodiment, the specific value of the preset number of times threshold is not limited here, and is adaptively adjusted based on actual needs. For example, the preset number of times threshold is 5, which is only used as an exemplary description.

[0104] In the embodiment of the present invention, the final self-test result is determined by the cumulative number of times the device self-test result fails and the size judgment result of the corresponding threshold, which can reduce the occasional error of failure and greatly improve the accuracy of the device self-test result.

[0105] Step B3: If all the second status data meet the preset upgrade conditions, it is determined that the device self-test result is passed.

[0106] In the embodiment of the present invention, the operating status of each BMS device and battery pack before the upgrade is fully taken into consideration. The device self-test result is determined by judging whether the operating data of each BMS device and its corresponding battery pack meets the preset upgrade conditions. This can greatly improve the accuracy of the device self-test result, thereby ensuring the success rate of subsequent battery pack upgrades.

[0107] Step 5: If the device self-test result is passed, it is determined that the device upgrade conditions are met.

[0108] In actual applications, LED lights are also designed on energy storage products proposed for certain needs. Taking into account the specific composition of such energy storage products, the upgrade method of this embodiment specifically designs an upgrade preparation action in which the LED status enters the upgrade light language flashing before the upgrade. The purpose is to use the LED status to enter the upgrade light language flashing to prompt the user of the upgrade status, which helps the user understand the upgrade progress and enhances the explainability of the upgrade process.

[0109] In this embodiment, the energy storage product also includes an LED light. After the equipment upgrade conditions are met, the upgrade method of this embodiment also includes: controlling the master device to perform preset upgrade preparation actions, wherein the preset upgrade preparation actions include setting the upgrade start flag, flashing the LED light, stopping the sending of other communication messages, prohibiting battery charging and discharging, and recording and saving current operating data. Specifically, before the master device performs the file transfer upgrade process for each slave device, relevant upgrade preparation actions are designed to remind the progress and status of the current upgrade, greatly enhancing the user experience and ensuring the success rate of the upgrade. It should be noted that the upgrade preparation actions in this embodiment can be set based on the update adaptability of the actual energy storage product.

[0110] Step 6: If the device self-test result is failed, it is determined that the device upgrade condition is not met.

[0111] In the embodiment of the present invention, when the first status data corresponding to the master device meets the preset upgrade conditions, that is, when the device self-test of the master device passes, the corresponding status data of each slave device currently running is detected and obtained, and the final device self-test result is determined based on it, and then based on the device self-test result, it is determined whether multiple BMS devices meet the device upgrade conditions. This not only ensures the accuracy of device self-test and improves the upgrade success rate, but also greatly simplifies the upgrade process.

[0112] Step S203: If the device upgrade condition is met, the master device is controlled to parse the upgrade firmware information, and based on the parsing result, a file transfer upgrade is performed on each slave device to achieve an upgrade of the corresponding battery pack of each slave device.

[0113] Specifically, the above step S203 includes:

[0114] Step S2031, control the master device to read the upgrade firmware information from the local storage, parse it to obtain the target upgrade file, and send the upgrade start instruction to each slave device. It should be noted that the target upgrade file is the header file information, which is used to record the upgrade file type, calculate the total number of firmware sub-packaging segments, header file verification, and send the firmware total verification to each slave device.

[0115] In this embodiment, the master BMS parses the upgraded firmware information from the corresponding storage address space named APP3 to obtain the upgraded firmware header file information.

[0116] Step S2032, in response to the received upgrade response results of each slave device, the target upgrade file is transmitted to each slave device in segments, so that each slave device is upgraded based on the received target upgrade file and generates an upgrade result, which includes upgrade success and upgrade failure.

[0117] Step S2033, receiving the upgrade results fed back by each slave device.

[0118] Step S2034: If the upgrade result is successful, the energy storage product is restarted to complete the upgrade of the corresponding battery pack of each slave device.

[0119] It should be noted that the process of updating the internal firmware of the battery pack to fix errors, add new functions or improve performance involves downloading the new firmware code to the storage device of the battery pack and replacing the old code; after the upgrade is completed, the battery pack will restart and run with the new firmware version, thereby improving the performance and functionality of the battery pack.

[0120] Step S2035, if the upgrade result is an upgrade failure, record the reason for the upgrade failure, and return to the step of sending an upgrade start instruction to each slave device to count the cumulative number of failures corresponding to the upgrade failure; when the cumulative number of failures exceeds the failure number threshold, end the current upgrade and report the corresponding upgrade failure reason to the server.

[0121] It should be noted that in this embodiment, the reasons for the upgrade failure are not limited here, and are based on the actual project adaptability settings, such as an error in confirming the header information from the BMS, or a timeout in the header information response, which is only used as an exemplary explanation.

[0122] In the embodiment of the present invention, through the file transmission upgrade process of the master device to each slave device, effective firmware upgrade of all slave devices can be achieved, which not only speeds up the upgrade operation process and saves upgrade costs, but also improves the success rate of remote upgrades.

[0123] It should be noted that, in this embodiment, while realizing the file transmission upgrade of the master device to each slave device, it also includes the upgrade of the master device itself, that is, the master BMS parses the firmware upgrade information and then performs its own firmware upgrade.

[0124] In a specific embodiment, since the BMS device of the existing home storage system (i.e., home storage product) cannot realize the internal upgrade function of the BMS device, a WIFI module (i.e., data collector) needs to be connected to all BMS devices to operate and upgrade each battery pack separately, which has the disadvantages of long time and cumbersome operation. Based on this, this embodiment proposes a system with multiple battery packs in parallel, in which only one data collector needs to be mounted on the host battery pack for network interaction, and the main BMS summarizes the current system real-time data, all slave BMS information, etc. and uploads them to the cloud server, and the host obtains the remote upgrade firmware through the network and saves it locally, and then transmits the firmware to all slave battery packs through the CAN communication file transfer packet sending method, and finally realizes the remote upgrade of the firmware of the entire system battery pack. Specifically, the above scheme realizes the internal upgrade between multiple BMS devices, and only realizes the common upgrade of other slave BMS devices after the main BMS device is upgraded, that is, the main BMS device realizes the file transmission upgrade of the upgrade firmware information to the slave BMS device. Figure 3 is a schematic diagram of the structure of a multi-battery pack parallel system; Figure 3 It can be seen that the specific upgrade process includes:

[0125] 1. Obtain the firmware upgrade process.

[0126] In this embodiment, multiple battery packs are connected in parallel (each battery pack corresponds to a BMS device), and the main device is mounted with a data collector to communicate with the server. Figure 4 This is a schematic diagram for obtaining firmware upgrades. It should be explained that COM0 and COM1 in the diagram are the communication interfaces of each BMS. Different BMSs are connected in sequence through the interfaces to achieve parallel connection of devices. Figure 4 , the process includes:

[0127] 1. When starting the system upgrade, the user starts the upgrade through the mobile phone APP or server web page settings, and the data collector will remotely pull the upgrade firmware from the server.

[0128] 2. After the data logger obtains the complete upgraded firmware, it uses the Xmode-1K file transfer protocol to send the firmware information to the main BMS through the RS485 hardware interface. It should be noted that the Xmode-1K file transfer protocol of the HyperTerminal provides a simple continuous file transfer protocol with a fixed packet length for communication between the service and the client based on a point-to-point connection; each packet contains 1024 bytes of file data and is responded to by the receiving client separately; only one file can be transferred at a time, and the transfer can only be restarted after failure.

[0129] 3. The main BMS needs to perform segment verification and full firmware verification on the firmware. If the verification fails, the upgrade is terminated. If the verification succeeds, the firmware valid code segment (hex file) in the upgrade firmware (bin file) is parsed out and saved in the upgrade firmware backup APP3 address of FLASH (where the FLASH address domain is: 0x08059800-0x0807E800, a total of 148k), and the firmware valid flag is written, and the firmware update action preparation flag is set. Specifically, the schematic diagram of the saved upgrade firmware information can be found in Figure 5 shown.

[0130] It should be noted that APP3 is related to the storage of remote upgrade files. It is a FLASH storage address space internally defined in the actual project, which is used to store the address of the application. The corresponding names of different applications can be adaptively determined based on actual needs. For example, the internally defined APP1 address space is the application running code area, the APP2 address space is the application backup / rollback code storage area, and the APP3 address space is the download storage area for new applications. This is only an example.

[0131] 2. Master-to-slave upgrade preparation process.

[0132] In this embodiment, after the master BMS device saves the complete upgrade firmware, it starts to prepare for the entire system upgrade as a leader. The specific process includes:

[0133] 1. Check whether the BMS host is ready, including whether the power is too low and about to shut down due to undervoltage, whether there is a communication anomaly, whether there is a conflict between the battery and the local node number, whether it is in the charging / discharging working state, and other states that prohibit upgrading. If the above upgrade conditions are not met, wait until the upgrade conditions are met before starting the next upgrade action.

[0134] 2. The master BMS device detects whether there is a slave in the system. If there is no slave, the host starts to upgrade itself; if there is a slave, it queries whether the system and slave status meet the aforementioned upgrade requirements.

[0135] 3. Check whether the whole system is ready, including whether all slaves are in a state where the battery is too low and about to be shut down due to undervoltage, communication abnormalities, node number conflicts, or are in a charging / discharging working state, etc., which prohibits upgrading.

[0136] 4. If the upgrade self-check fails, the host starts the upgrade query timing and initiates the upgrade self-check query again every 10 minutes; if the last upgrade self-check query still fails after 1 hour, the master-to-slave upgrade is abandoned and the upgrade action is terminated.

[0137] 5. If the upgrade self-test passes, the host starts to send upgrade instructions to all battery packs, and will start after 5S. All battery packs begin preparations for the upgrade, including: setting the upgrade start flag, the LED status enters the upgrade light flashing, stopping the sending of non-upgrade related communication messages, disconnecting the charge and discharge MOS to prohibit the charge and discharge action, and recording and saving the key data of the current operation.

[0138] 6. The host starts the preparation work before the upgrade. It parses and obtains the upgrade firmware header file information from APP3 to record the upgrade file type, calculate the total number of firmware sub-packets, header file verification, and send the firmware total verification to the slave; the slave waits to receive the upgrade start instruction sent by the host. Specifically, the upgrade preparation process is as follows: Figure 6 shown.

[0139] 3. Master-to-slave file transfer process.

[0140] In this embodiment, the function required by the host to process the file transfer upgrade process of the slave is MstMainFunction(), and the transmission operation cycle is 100ms, which is divided into 17 transmission processes, namely, upgrade waiting, upgrade start, start response, upgrade handshake, handshake response, header file sending, header information confirmation, segment information acquisition, segment start, segment start confirmation, segment information sending, segment end, segment end confirmation, upgrade completion, upgrade completion confirmation, upgrade exit, and upgrade this machine. Specifically, each process is described as follows:

[0141] 1. Upgrade waiting: that is, upgrade initialization, upgrade preparation work begins, record the number of online batteries, and initialize upgrade temporary variables.

[0142] 2. Upgrade start: Send upgrade start message.

[0143] 3. Start response: detect the response result of the slave, resend if timeout, and exit if failure.

[0144] 4. Upgrade handshake: send handshake message.

[0145] 5. Handshake response: detect the response result of the slave, resend if timeout, and exit if failure.

[0146] 6. Header file sending: Send key information of firmware header file.

[0147] 7. Header information confirmation: detect the response result of the slave, resend if timeout, and exit if failure.

[0148] 8. Segment information acquisition: 1K bytes are read from the local storage of APP3 firmware each time and encapsulated into 1036-byte data in bin file format.

[0149] 9. Segment start: Send segment start message.

[0150] 10. Segment start confirmation: detect the response result of the slave, resend if timeout, and exit if failure.

[0151] 11. Segment information transmission: Start the segment transmission task TransCanSection() and do a 500ms transmission timeout count. In segment transmission, the 1036-byte segment data is split into multiple packets in the TIM timer through the TransCanSection() function, and the transmission is completed in a 1ms timing cycle.

[0152] 12. Segment end: After the segment information is sent, the host sends the segment end message eSctFin_Yes to notify the slave to verify and store the single-segment firmware.

[0153] 13. Segment end confirmation: detect the slave response result, resend the current segment information if it times out, and exit if it fails.

[0154] 14. Upgrade completed: After all firmware is sent, the host sends the upgrade completed eSctFin_FileOK to notify the slave to verify all firmware and respond with the upgrade completion result.

[0155] 15. Upgrade completion confirmation: Check the upgrade completion result of the slave machine, and exit if failed.

[0156] 16. Upgrade exit: Send the upgrade exit message and judge the result of this file transfer. If the upgrade is successful, the local upgrade will be started. If the upgrade fails, the upgrade data information will be cleared and the upgrade process will be exited.

[0157] 17. Upgrade the machine: After the host completes the file transfer to the slave, the host writes its own firmware upgrade flag and executes the restart action to complete its own upgrade task.

[0158] In this embodiment, the above-mentioned master-to-slave file transmission stages refer to Figure 7 ; Figure 8 This is a schematic diagram of file transfer from the host to the slave. It should be noted that Figure 8 The character 'C' in the ID is the primary index identifier, which is combined with different values ​​to indicate the specific transmission stage. Figure 7 Adaptive understanding of content during the transmission phase.

[0159] Specifically, Figure 8 The use of C1 and C4 is to facilitate users to quickly understand the upgraded message content through the flowchart, because they represent the main index in the CAN ID of the upgrade message, which is convenient for users to understand and identify. The specific index identification is shown in Table 1 below.

[0160] Table 1

[0161]

[0162] Specifically, C1 in Table 1 means the primary index of the frame ID. When analyzing a message, the current message content can be quickly identified through C1 and C5.

[0163] 4. Upgrade completed.

[0164] In this embodiment, after the upgrade is completed, whether the upgrade is successful or not needs to be analyzed again. The corresponding analysis content is referred to below.

[0165] 1. If the master-to-slave file transfer upgrade fails within a single timeout, the host records the reasons for the upgrade failure, such as firmware header information, failed process node, failure reason, failed slave battery pack node number, and repeated upgrade times.

[0166] In this embodiment, since the master and slave machines are constantly communicating and interacting during the upgrade process, sending and receiving responses, the master machine may respond incorrectly or respond overtime to the slave machine at different upgrade stages, which may eventually lead to upgrade termination / failure. The upgrade failure reason and the node number of the abnormal slave machine need to be recorded. Specifically, the upgrade failure reasons include:

[0167] 1. Upgrade preparation is not ready; 2. Upgrade start response failed; 3. Upgrade start response timed out; 4. Upgrade handshake response failed; 5. Upgrade handshake response timed out; 6. Header file information confirmation error; 7. Header file information response timed out; 8. Segment information reading error; 9. Segment information reception verification failed; 10. Segment information reception response timed out; 11. Segment start response timed out; 12. Segment start confirmation response timed out, etc.

[0168] 2. The host starts to repeatedly upgrade the timer. Every 1 minute (the time is configurable), the host initiates the file transfer upgrade to the slave again. The upgrade is repeated 3 times (the number of times is configurable). If it still fails, the host ends the upgrade and reports the reason for the upgrade failure to the server.

[0169] 3. If the master-to-slave file transfer upgrade is successful, the FLASH upgrade firmware backup APP3 of all battery packs in the system now stores the valid firmware information that needs to be upgraded. The BMS device writes the firmware validity flag and upgrade action flag into the corresponding memory address, sets the system restart flag, records the current system key operation data, and then restarts the system. The BOOT program will read the corresponding flag bit, write the APP3 firmware into the microcontroller running Code segment, set the corresponding upgrade completion flag, and complete the backup of the upgraded firmware, and then jump back to the APP running program. After the BMS device completes the upgrade action, it can operate normally. Specifically, Fig. 9 This is a flowchart of the upgrade.

[0170] In summary, this embodiment can achieve internal upgrade of the battery pack under the parallel system by improving the communication protocol docking process of the software without changing the system architecture and hardware interface of the existing energy storage product, which can effectively save product costs, increase the battery upgrade speed, simplify the upgrade operation process, and improve the success rate of remote upgrades.

[0171] In this embodiment, an upgrade device is also provided, which is used to implement the above-mentioned embodiments and preferred implementation modes, and the descriptions that have been made will not be repeated. As used below, the term "module" refers to a combination of software and / or hardware that can implement a predetermined function. Although the devices described in the following embodiments are preferably implemented in software, the implementation of hardware, or a combination of software and hardware, is also possible and conceivable.

[0172] The present invention provides an upgrade device, which is applied to an energy storage product. The energy storage product is composed of multiple BMS devices connected in parallel, each BMS device corresponds to a battery pack, and the multiple BMS devices include a master device and at least one slave device, such as Fig.10 As shown, the device comprises:

[0173] The acquisition module 1001 is used to acquire the upgrade firmware information.

[0174] The detection module 1002 is used to detect whether a plurality of BMS devices meet the device upgrade conditions.

[0175] The upgrade module 1003 is used to control the master device to parse the upgrade firmware information if the device upgrade conditions are met, and to perform file transfer upgrade on each slave device based on the analysis result to achieve the upgrade of the corresponding battery pack of each slave device.

[0176] In some optional embodiments, the acquisition module 1001 includes: an acquisition sub-module, which is used to respond to an upgrade request generated when a user initiates an upgrade through a mobile phone APP or server settings, control the main device to obtain upgrade firmware information from the server through a data collector, and store the upgrade firmware information locally.

[0177] In some optional implementations, the acquisition submodule includes: a verification unit, which is used to verify the upgrade firmware information; if the verification fails, returning to the step of obtaining the upgrade firmware information; if the verification succeeds, executing the step of locally storing the upgrade firmware information.

[0178] In some optional embodiments, the detection module 1002 includes: a first detection submodule and a second detection submodule; wherein the first detection submodule is used to obtain the first status data of the master device; when the first status data meets the preset upgrade condition, detect whether there is a slave device in a working state; if there is at least one slave device in a working state, obtain the second status data corresponding to each slave device in a working state respectively, and judge whether each second status data meets the preset upgrade condition; determine the device self-test result based on all the second status data, and the device self-test result includes pass and fail; if the device self-test result is pass, it is determined that the device upgrade condition is met; if the device self-test result is fail, it is determined that the device upgrade condition is not met; the second detection submodule is used to judge whether each second status data meets the preset upgrade condition respectively; if there is at least one second status data that does not meet the preset upgrade condition, determine that the device self-test result is fail; if all the second status data meet the preset upgrade condition, determine that the device self-test result is pass.

[0179] In some optional embodiments, the fourth detection unit includes: a repeating sub-unit, which is used to return to the step of obtaining the first status data of the master device after a first preset time, or to obtain the first status data of the master device and the second status data corresponding to each slave device, and to count the cumulative number of times the device self-test result fails; if the cumulative number exceeds a preset number threshold, it is finally determined that the device self-test result is failed.

[0180] In some optional embodiments, the third detection submodule includes: a preparation unit, used to control the main device to perform preset upgrade preparation actions, wherein the preset upgrade preparation actions include setting an upgrade start flag, flashing an LED light, stopping sending other communication messages, prohibiting battery charging and discharging, and recording and saving current operating data.

[0181] In some optional implementations, the upgrade module 1003 includes: a first upgrade submodule, a second upgrade submodule, a third upgrade submodule, a fourth upgrade submodule and a fifth upgrade submodule; wherein the first upgrade submodule is used to control the master device to read the upgrade firmware information from the local storage, parse it to obtain the target upgrade file, and send an upgrade start instruction to each slave device, wherein the target upgrade file is used to record the upgrade file type, calculate the total number of firmware subpackage segments, header file verification, and send a firmware total verification to each slave device; the second upgrade submodule is used to respond to the upgrade response results received from each slave device, and transmit the target upgrade file to each slave device in segments, so as to Enable each slave device to upgrade based on the received target upgrade file and generate an upgrade result, which includes upgrade success and upgrade failure; a third upgrade sub-module is used to receive the upgrade results fed back by each slave device; a fourth upgrade sub-module is used to restart the energy storage product to complete the upgrade of the corresponding battery pack of each slave device if the upgrade result is an upgrade success; a fifth upgrade sub-module is used to record the reason for the upgrade failure if the upgrade result is an upgrade failure, and return to the step of sending an upgrade start instruction to each slave device, and count the cumulative number of failures corresponding to the upgrade failure; when the cumulative number of failures exceeds the failure number threshold, end the current upgrade and report the corresponding upgrade failure reason to the server.

[0182] The further functional description of each of the above modules is the same as that of the above corresponding embodiments and will not be repeated here.

[0183] The upgrade device in this embodiment is presented in the form of a functional unit, where the unit refers to an ASIC (Application Specific Integrated Circuit) circuit, a processor and memory that executes one or more software or fixed programs, and / or other devices that can provide the above functions.

[0184] The upgrade device of the embodiment of the present invention realizes the effective upgrade of the battery pack inside the energy storage product, which can save product upgrade costs, simplify the upgrade operation process, and increase the battery upgrade speed, thereby greatly improving the success rate of remote upgrades and satisfying the user experience.

[0185] An upgrade system is also provided in an embodiment of the present invention. The system includes a server, a data collector and an energy storage product. The energy storage product is composed of multiple BMS devices in parallel. Each BMS device corresponds to a battery pack. The multiple BMS devices include a master device and at least one slave device. The master device is connected to the server through the data collector. The energy storage product also includes an LED lamp and a controller. Fig.11 is a schematic diagram of the structure of the controller provided by an optional embodiment of the present invention, such as Fig.11 As shown, the controller includes: one or more processors 10, a memory 20, and interfaces for connecting various components, including high-speed interfaces and low-speed interfaces. The various components are connected to each other using different buses for communication, and can be installed on a common mainboard or installed in other ways as needed. The processor can process instructions executed in the controller, including instructions stored in or on the memory to display graphical information of the GUI on an external input / output device (such as a display device coupled to the interface). In some optional embodiments, if necessary, multiple processors and / or multiple buses can be used together with multiple memories and multiple memories. Similarly, multiple controllers can be connected, and each controller provides some necessary operations (for example, as a server array, a group of blade servers, or a multi-processor system). Fig.11 A processor 10 is taken as an example.

[0186] The processor 10 may be a central processing unit, a network processor or a combination thereof. The processor 10 may further include a hardware chip. The hardware chip may be a dedicated integrated circuit, a programmable logic device or a combination thereof. The programmable logic device may be a complex programmable logic device, a field programmable gate array, a general purpose array logic or any combination thereof.

[0187] The memory 20 stores instructions executable by at least one processor 10, so that at least one processor 10 executes the method shown in the above embodiment.

[0188] The memory 20 may include a program storage area and a data storage area, wherein the program storage area may store an operating system, an application required by at least one function; the data storage area may store data created according to the use of the controller, etc. In addition, the memory 20 may include a high-speed random access memory, and may also include a non-transient memory, such as at least one disk storage device, a flash memory device, or other non-transient solid-state storage device. In some optional embodiments, the memory 20 may optionally include a memory remotely arranged relative to the processor 10, and these remote memories may be connected to the controller via a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0189] The memory 20 may include a volatile memory, such as a random access memory; the memory may also include a non-volatile memory, such as a flash memory, a hard disk or a solid state drive; the memory 20 may also include a combination of the above types of memory.

[0190] The controller also includes a communication interface 30 for the main control chip to communicate with other devices or a communication network.

[0191] A computer-readable storage medium is also provided in an embodiment of the present invention. The method according to the embodiment of the present invention can be implemented in hardware, firmware, or can be implemented as a computer code that can be recorded in a storage medium, or can be implemented as a computer code that is originally stored in a remote storage medium or a non-temporary machine-readable storage medium and will be stored in a local storage medium and downloaded through a network, so that the method described herein can be stored in such software processing on a storage medium using a general-purpose computer, a dedicated processor, or programmable or dedicated hardware. Among them, the storage medium can be a magnetic disk, an optical disk, a read-only storage memory, a random access memory, a flash memory, a hard disk or a solid-state hard disk, etc.; further, the storage medium can also include a combination of the above types of memories. It can be understood that a computer, a processor, a microprocessor main control chip or programmable hardware includes a storage component that can store or receive software or computer code. When the software or computer code is accessed and executed by a computer, a processor or hardware, the method shown in the above embodiment is implemented.

[0192] Although the embodiments of the present invention have been described in conjunction with the accompanying drawings, those skilled in the art may make various modifications and variations without departing from the spirit and scope of the present invention, and such modifications and variations are all within the scope defined by the appended claims.

Claims

1. An upgrade method, applied to energy storage products, characterized in that: The energy storage product is composed of a plurality of BMS devices connected in parallel, each BMS device corresponds to a battery pack, and the plurality of BMS devices include a master device and at least one slave device. The method includes: Get the firmware upgrade information; Check whether multiple BMS devices meet the equipment upgrade conditions; If the device upgrade conditions are met, the master device is controlled to parse the upgrade firmware information, and based on the parsing result, the file transfer upgrade is performed on each slave device to achieve the upgrade of the corresponding battery pack of each slave device.

2. The upgrading method according to claim 1, characterized in that: The detecting whether the multiple BMS devices meet the device upgrade conditions includes: Acquire first status data of the master device; When the first state data meets the preset upgrade condition, detecting whether there is a slave device in a working state; If there is at least one slave device in a working state, obtaining second state data corresponding to each slave device in a working state respectively; Determine a device self-test result based on all the second status data, wherein the device self-test result includes a pass or a fail; If the device self-test result is passed, it is determined that the device upgrade condition is met; If the device self-test result is failed, it is determined that the device upgrade condition is not met.

3. The upgrading method according to claim 2, characterized in that: The determining of the device self-test result based on all the second state data includes: Determine whether each second state data satisfies a preset upgrade condition; If at least one of the second status data does not satisfy the preset upgrade condition, determining that the device self-test result is failed; If all the second status data meet the preset upgrade conditions, it is determined that the device self-test result is passed.

4. The upgrading method according to claim 3, characterized in that: After determining that the device self-test result is failed, the method further includes: After a first preset time, return to the step of obtaining the first status data of the master device, or obtaining the first status data of the master device and the second status data corresponding to each slave device, and count the cumulative number of times the device self-test result fails; If the accumulated number of times exceeds the preset number threshold, the device self-test result is finally determined to be failed.

5. The upgrading method according to claim 1, characterized in that: The main device is connected to the server through a data collector, and the acquisition of the upgrade firmware information includes: In response to receiving an upgrade request generated when a user starts an upgrade through a mobile phone APP or server settings, the control main device obtains upgrade firmware information from the server through a data collector and stores the upgrade firmware information locally.

6. The upgrading method according to claim 5, characterized in that: Before locally storing the upgraded firmware information, the method further includes: Verifying the upgraded firmware information; If the verification fails, return to the step of obtaining the upgrade firmware information; If the verification is successful, the step of locally storing the upgraded firmware information is performed.

7. The upgrading method according to claim 5, characterized in that: The control master device parses the upgrade firmware information, and performs file transfer upgrade on each slave device based on the parsing result to implement the upgrade of the corresponding battery pack of each slave device, including: Control the master device to read the upgrade firmware information from the local storage, parse it to obtain the target upgrade file, and send the upgrade start instruction target upgrade file to each slave device; In response to the received upgrade response results of each slave device, the target upgrade file is transmitted to each slave device in segments, so that each slave device is upgraded based on the received target upgrade file, and an upgrade result is generated, wherein the upgrade result includes upgrade success and upgrade failure; Receive upgrade results fed back by each slave device; If the upgrade result is successful, restart the energy storage product to complete the upgrade of the corresponding battery pack of each slave device; If the upgrade result is an upgrade failure, the reason for the upgrade failure is recorded, and the step of sending an upgrade start instruction to each slave device is returned to count the cumulative number of failures corresponding to the upgrade failure; when the cumulative number of failures exceeds the failure number threshold, the current upgrade is terminated and the corresponding upgrade failure reason is reported to the server.

8. An upgrade device, applied to energy storage products, characterized in that: The energy storage product is composed of multiple BMS devices connected in parallel, each BMS device corresponds to a battery pack, and the multiple BMS devices include a master device and at least one slave device. The device includes: An acquisition module is used to obtain upgrade firmware information; A detection module is used to detect whether multiple BMS devices meet the equipment upgrade conditions; The upgrade module is used to control the master device to parse the upgrade firmware information if the device upgrade conditions are met, and to perform file transfer upgrade on each slave device based on the analysis result to achieve the upgrade of the corresponding battery pack of each slave device.

9. An upgrade system, characterized in that: The system includes a server, a data collector and an energy storage product. The energy storage product is composed of multiple BMS devices connected in parallel. Each BMS device corresponds to a battery pack. The multiple BMS devices include a master device and at least one slave device. The master device is communicatively connected to the server through the data collector. The energy storage product also includes a controller, wherein the controller includes a memory and a processor. The memory and the processor are communicatively connected to each other. Computer instructions are stored in the memory. The processor executes the computer instructions to execute the upgrade method described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores computer instructions, and the computer instructions are used to enable a computer to execute the upgrading method according to any one of claims 1 to 7.

Images