Energy storage power station whole station bms device upgrading method, mbmu device and bms device

Abstract

The application provides a kind of energy storage power station whole station BMS equipment upgrading method, MBMU equipment and BMS equipment, it is related to BMS equipment upgrading field.The battery management system BMS equipment includes a host and multiple slaves in multiple master control management units MBMU equipment;The method is applied to host, and the method comprises: receiving local whole station upgrade package;Wherein, the whole station upgrade package includes the sub-upgrade package of each device in MBMU layer, SBMU layer and BMU layer;Whole station upgrade package is sent to each slave, so that each slave is based on the branch where it is located, from whole station upgrade package, slave upgrade package is parsed and extracted, and the sub-upgrade package of SBMU equipment and BMU equipment on the branch where slave upgrade package is located is issued to corresponding SBMU equipment and BMU equipment, to upgrade.The application can improve the efficiency and reliability of upgrading.

Description

Technical Field

[0001] This invention relates to the field of BMS equipment upgrade technology, and in particular to a method for upgrading the entire BMS equipment of an energy storage power station, MBMU equipment, and BMS equipment. Background Technology

[0002] As the core control unit of an energy storage system, the Battery Management System (BMS) typically adopts a three-layer architecture, including the top-level Master Battery Management Unit (MBMU), the middle-level Slave Battery Management Unit (SBMU), and the bottom-level Battery Management Unit (BMU).

[0003] The MBMU is responsible for communicating with upper-level systems, such as the Energy Management System (EMS) or the Power Conversion System (PCS), and for the unified management and scheduling of the SBMU devices in its subordinate branches. Each SBMU manages a battery cluster or battery pack and is responsible for the acquisition and equalization control of voltage, current, and temperature within that cluster. Each SBMU manages multiple BMUs, and each BMU is directly connected to each cell or battery module to perform underlying functions such as single-cell voltage detection, temperature detection, and passive equalization.

[0004] As the scale of energy storage power stations continues to expand, how to efficiently and reliably complete firmware upgrades for all levels of equipment across the entire station has become a pressing technical problem that needs to be solved in the field of energy storage operation and maintenance.

[0005] Currently, the industry mainly uses two methods to achieve full-site batch upgrades of BMS: remote upgrades and local upgrades. In remote upgrades, maintenance personnel distribute upgrade packages to various devices within the site via EMS or a cloud management platform. This method can achieve a certain degree of automated batch upgrades, but it has significant limitations: remote upgrades heavily rely on the normal operation of the site's network communication and the host computer system, making them impossible to implement in scenarios where a host computer is unavailable.

[0006] In local upgrade methods, a common practice is for maintenance personnel to bring storage media such as USB drives to the site and import upgrade packages into each MBMU, SBMU, and BMU device to complete the upgrade. This method does not rely on a network or host computer, but when dealing with hundreds or thousands of devices, the operation is extremely cumbersome and time-consuming, and manual operation is prone to human errors such as omissions or selecting the wrong upgrade package.

[0007] It is evident that existing BMS upgrade technologies, such as remote solutions that rely on host computers, are unsuitable for on-site maintenance scenarios without network or host computers; while local solutions that do not rely on host computers suffer from low operational efficiency. Therefore, how to achieve efficient and reliable batch upgrades of all BMS devices has become an urgent technical problem to be solved in this field. Summary of the Invention

[0008] This invention provides a method for upgrading the entire BMS equipment of an energy storage power station, an MBMU device, and a BMS device, to solve the problem of low efficiency in current local upgrade methods for the entire BMS equipment.

[0009] In a first aspect, embodiments of the present invention provide a method for upgrading the entire BMS equipment of an energy storage power station. The BMS equipment includes multiple Master Management Units (MBMUs) comprising a master unit and multiple slave units. The method is applied to the master unit and includes: Receive the local full-site upgrade package; the full-site upgrade package includes sub-upgrade packages for each device in the MBMU layer, the SBMU layer, and the BMU layer; The full-site upgrade package is sent to each slave device, so that each slave device can parse and extract the slave upgrade package from the full-site upgrade package based on its own branch, and send the sub-upgrade packages corresponding to the SBMU and BMU devices on its own branch to the corresponding SBMU and BMU devices for upgrade. The slave upgrade package includes the slave's own sub-upgrade package, as well as the sub-upgrade packages corresponding to the SBMU and BMU devices on the branch where the slave is located.

[0010] In one possible implementation, after sending the full-site upgrade package to each slave device, the method further includes: Receive upgrade package verification information sent by each slave device; wherein, the upgrade package verification information is generated by each slave device through a consistency comparison by exchanging verification values, and is used to indicate whether the full-site upgrade packages received by each slave device are consistent; If there are slave devices with inconsistent verification values ​​in the upgrade package verification information, then resend the full-site upgrade package to that slave device. Alternatively, resend the full-site upgrade package to the slave device that did not report the upgrade package verification information.

[0011] In one possible implementation, the host is determined in the following way: The MBMU device that detects the insertion of the local storage medium confirms itself as the host and sends a broadcast statement to other MBMU devices; the local storage medium contains a site-wide upgrade package.

[0012] In one possible implementation, before sending the full-site upgrade package to each slave device, the method further includes: An upgrade preparation command is sent to each slave device; the upgrade preparation command is used to instruct each slave device to delete the upgrade package it already holds locally.

[0013] Secondly, embodiments of the present invention provide a method for upgrading the entire BMS equipment of an energy storage power station, wherein the BMS equipment includes a master unit and multiple slave units among the multiple MBMU devices; the method is applied to any one of the multiple slave units, and the method includes: Receive the full-site upgrade package sent by the host; the full-site upgrade package includes sub-upgrade packages for each device in the MBMU layer, SBMU layer and BMU layer; Based on its own branch, the slave upgrade package is parsed and extracted from the full-site upgrade package. The slave upgrade package includes the slave's own sub-upgrade package, as well as the sub-upgrade packages corresponding to the SBMU and BMU devices on the branch where the slave is located. The sub-upgrade package corresponding to the SBMU and BMU devices on the branch where the slave device is located is sent to the SBMU and BMU devices on the branch where it is located, so as to upgrade itself and the SBMU and BMU devices on the branch where it is located.

[0014] In one possible implementation, after receiving the site-wide upgrade package from the host, the method further includes: The system calculates a checksum based on the received full-site upgrade package and exchanges checksums with other slave machines for consistency comparison. Based on the consistency comparison results, upgrade package verification information is generated and sent to the host; If the consistency comparison result is inconsistent, then the full-site upgrade package sent by the host will be received again; Alternatively, if the consistency comparison result is consistent, then upgrade package verification information is generated and sent to the host; If the consistency comparison result is inconsistent, no upgrade package verification information will be generated, and the full-site upgrade package issued by the host will be received again.

[0015] In one possible implementation, the slave device is determined in the following way: After not detecting the insertion of local storage media and receiving a broadcast declaration, it determines itself to be a slave device.

[0016] In one possible implementation, before receiving the site-wide upgrade package from the host, the method further includes: Receive upgrade preparation instructions from the host; Check if you have the full site update package; If so, delete any full-site upgrade packages that you already own.

[0017] Thirdly, embodiments of the present invention provide an MBMU device, including a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the method as described in the first aspect or any possible implementation of the first aspect, or the method as described in the second aspect or any possible implementation of the second aspect.

[0018] Fourthly, embodiments of the present invention provide a BMS device, including multiple MBMU devices as provided in the third aspect; the MBMU device includes a master and multiple slave devices.

[0019] In this embodiment of the invention, within the MBMU layer of the BMS device, one MBMU device is designated as the master, and the remaining MBMU devices are designated as slaves. During local upgrades, the entire upgrade package is sent locally to the master. The master, based on a pre-stored organizational structure, distributes the upgrade package to the other MBMU devices acting as slaves. Upon receiving the upgrade package from the master, the slave MBMU devices parse and extract their own upgrade packages, as well as those of the SBMU and BMU devices on their respective tributaries, and then distribute these upgrade packages to the SBMU and BMU devices on their tributaries. In this way, all devices requiring upgrades receive the corresponding upgrade packages, achieving a full-site upgrade. Therefore, this embodiment of the invention eliminates the need for manual, step-by-step operations during local upgrades. The entire upgrade package is sent locally to the master, which automatically distributes it to each slave device, achieving a full-site upgrade. This is more efficient and reliable than traditional manual operations. Attached Figure Description

[0020] Figure 1 This is a schematic diagram of the structure of the BMS device provided in an embodiment of the present invention; Figure 2 This is a flowchart illustrating the implementation of the method for upgrading the entire BMS equipment of an energy storage power station according to an embodiment of the present invention. Figure 3 This is a flowchart illustrating the implementation of another energy storage power station BMS equipment upgrade method provided in this embodiment of the invention; Figure 4 This is a flowchart of the whole-site BMS equipment upgrade process provided in the embodiment of the present invention. Detailed Implementation

[0021] The embodiments of the present invention will now be described in detail with reference to the accompanying drawings.

[0022] Figure 1 This is a schematic diagram of the structure of the BMS device provided in an embodiment of the present invention, as shown below. Figure 1 As shown.

[0023] The battery management system (BMS) consists of a three-layer structure: the top MBMU layer, the middle SBMU layer, and the bottom BMU layer. Within the MBMU layer, each MBMU manages and schedules the SBMU devices in its subordinate branches. Each SBMU manages a battery cluster or battery group, responsible for voltage, current, and temperature acquisition and equalization control within that cluster. Each SBMU manages one or more BMUs, and each BMU is directly connected to each individual cell or battery module, performing basic functions such as single-cell voltage detection, temperature detection, and passive equalization.

[0024] Traditional remote and online upgrades have limitations. While some current solutions employ a chain-like forwarding approach between MBMU devices for upgrades—where a source device receives the upgrade package and forwards it to the nearest device, which then relays the message until all devices have completed the upgrade—this method, while eliminating the need for a host computer, relies on the physical distance between devices for the upgrade path, making the path uncontrollable. Furthermore, a failure in any intermediate device can prevent all downstream devices from receiving the upgrade package, resulting in a wide-ranging impact.

[0025] This invention differs from traditional methods in that the MBMU layer within the BMS device includes a master unit and multiple slave units. A full-site upgrade is achieved by importing the full-site upgrade package into the master unit, which then distributes it to the slave units. Compared to traditional methods, this approach not only enables local upgrades even when offline or lacking a host computer, but also reduces the workload for maintenance personnel, improves upgrade efficiency, prevents missed upgrades, and enhances upgrade reliability.

[0026] Figure 2 This is a flowchart illustrating the implementation of the energy storage power station BMS equipment upgrade method provided in this embodiment of the invention. The following is a summary of the process. Figure 1 The provided BMS device structure illustrates this method. For example... Figure 2 As shown, this method is applied to a host in an MBMU device, and the method may include: Step 110: Receive the local full-site upgrade package; wherein, the full-site upgrade package includes sub-upgrade packages for each device in the MBMU layer, the SBMU layer, and the BMU layer.

[0027] The host can import the local full-site upgrade package received from the local storage medium. Specifically, when an external storage medium is detected, the host automatically reads the pre-stored full-site upgrade package in the storage medium and stores the full-site upgrade package in the host's local storage.

[0028] Optionally, after reading the full-site upgrade package, the host can also perform an integrity check on the package to ensure that it has not been tampered with or damaged. If the check passes, the reception is confirmed as successful; if the check fails, an error message is output to prompt the user to replace or re-import the upgrade package.

[0029] Besides local use, the method provided in this embodiment of the invention can also be applied to remote upgrades. Accordingly, the host can receive a remote full-site upgrade package. Specifically, the host establishes a communication connection with a remote server through its communication interface. The host sends an upgrade query request to the remote server, wherein the upgrade query request carries the host's own device identification information and current version information. Based on the request, the remote server determines whether a full-site upgrade package applicable to all BMS devices of the energy storage power station exists. If it exists, the remote server sends the full-site upgrade package to the host. The host receives the full-site upgrade package and stores it in its local memory.

[0030] The full-site upgrade package can be a single complete upgrade package file or a collection of upgrade packages consisting of multiple sub-upgrade packages. It contains the upgrade firmware required by each device in the MBMU, SBMU, and BMU layers. Upgrade packages at each layer can be organized according to device type, device identifier, or branch number to ensure accurate extraction during subsequent parsing.

[0031] Step 120: Send the full-site upgrade package to each slave device, so that each slave device can parse and extract the slave upgrade package from the full-site upgrade package based on its own branch, and send the sub-upgrade packages corresponding to the SBMU and BMU devices on its own branch to the corresponding SBMU and BMU devices for upgrade.

[0032] The slave upgrade package includes the slave's own sub-upgrade package, as well as the sub-upgrade packages corresponding to the SBMU and BMU devices on the branch where the slave is located.

[0033] After receiving and verifying the full-site upgrade package, the host searches for all slave devices and sends the package to each slave device through a preset communication link.

[0034] Specifically, the host establishes communication connections with each slave device through its communication interface. The host sends a complete full-site upgrade package to each slave device sequentially, either via broadcast or unicast. Since the communication link quality between each slave device and the host may vary, the host can further receive reception confirmation and / or verification information from each slave device after sending the package to ensure that each slave device has received the full-site upgrade package completely and correctly.

[0035] For example, the host sends the full-site upgrade package to each slave device sequentially using unicast. In this mode, the host sends the full-site upgrade package to each slave device one by one according to a preset slave device list, and only sends it to the next slave device after receiving a successful reception confirmation from the current slave device. Compared to broadcast, unicast communication is more reliable and easier to troubleshoot, but its distribution efficiency is slightly lower. The host can flexibly choose between broadcast or unicast methods according to actual needs.

[0036] After receiving the full-site upgrade package from the master, each slave device parses and extracts its own upgrade package. This slave upgrade package includes the slave's own upgrade package, as well as the upgrade packages corresponding to the SBMU and BMU devices on its tributary. After parsing, the slave device then distributes the sub-upgrade packages corresponding to the SBMU and BMU devices on its tributary to the respective SBMU and BMU devices.

[0037] Specifically, each slave device pre-stores its own branch identifier information, which is used to uniquely identify the branch to which the slave device belongs. Based on the branch identifier information, the slave device parses the full-site upgrade package and extracts the set of upgrade packages corresponding to its own branch, which is the slave upgrade package.

[0038] After extracting the slave upgrade package of its own branch, the slave device further parses three sub-parts from the slave upgrade package: MBMU self upgrade package, SBMU device upgrade package, and BMU device upgrade package.

[0039] For SBMU device upgrade packages, the slave device sends the SBMU device upgrade package to each SBMU device on that tributary through the internal communication link of its tributary, so as to instruct each SBMU device to perform firmware upgrade based on the received upgrade package.

[0040] For BMU device upgrade packages, the slave device also sends the BMU device upgrade package to each BMU device on the branch through the internal communication link of the branch, so as to instruct each BMU device to perform firmware upgrade based on the received upgrade package.

[0041] Optionally, when the slave device sends out SBMU device upgrade packages and BMU device upgrade packages, it can broadcast them simultaneously to all SBMU devices and BMU devices on the branch, or it can unicast them separately according to the target address of each device.

[0042] When each slave device parses and extracts its upgrade package, the master device parses and extracts its own upgrade package from the global upgrade package. The master upgrade package includes the master device itself, as well as the upgrade packages for the SBMU and BMU devices on its own branch. After extraction, the master device then distributes the corresponding upgrade packages for the SBMU and BMU devices on its own branch to the respective SBMU and BMU devices.

[0043] After the upgrade package is sent out, the host receives upgrade package verification information from each slave device, as well as from the SBMU and BMU devices on its own branch. Once the verification information is confirmed to be accurate, the host sends upgrade commands to each slave device, or the devices begin upgrading after a preset time. After the upgrade is complete, the host receives the corresponding upgrade results to generate log information.

[0044] In summary, compared to traditional methods, this embodiment of the invention designates one MBMU device as the master and the remaining MBMU devices as slaves within the MBMU layer of the BMS device. During local upgrades, the entire upgrade package is sent locally to the master. The master, based on a pre-stored organizational structure, distributes the upgrade package to the other MBMU devices acting as slaves. Upon receiving the upgrade package from the master, the slave MBMU devices parse and extract their own upgrade packages, as well as those of the SBMU and BMU devices on their respective tributaries, and then distribute these upgrade packages to the SBMU and BMU devices on their tributaries. In this way, all devices requiring upgrades receive the corresponding upgrade package, achieving a full-site upgrade. Therefore, this embodiment of the invention eliminates the need for manual, step-by-step operations during local upgrades. The entire upgrade package is automatically sent to each slave device after being sent locally to the master, resulting in a more efficient and reliable upgrade compared to traditional manual methods.

[0045] The method applied to a host provided by the embodiments of the present invention will be described in detail below with reference to some optional embodiments.

[0046] In an optional embodiment, the host is determined in the following way: The MBMU device that detects the insertion of the local storage medium confirms itself as the host and sends a broadcast statement to other MBMU devices; the local storage medium contains a site-wide upgrade package.

[0047] The local storage medium is a pluggable external storage device, including but not limited to USB flash drives, SD cards, and external hard drives. Each MBMU device has a corresponding interface. When an external storage medium is inserted into this interface, the MBMU device identifies itself as the host and sends a broadcast declaration to other MBMU devices. Simultaneously, the host detects and reads the full-site upgrade package stored within the medium using the corresponding communication protocol.

[0048] Optionally, after reading the upgrade package, the host performs an integrity check on it. If the check passes, the host confirms successful reception; if the check fails, an error message is output.

[0049] In practical applications of energy storage power stations, since the system typically contains multiple MBMU devices, it's possible that multiple maintenance personnel may insert local storage media containing upgrade packages into different MBMU devices, or that storage media might not have been removed promptly after the previous upgrade, and a new storage media might be inserted into another MBMU device during the current upgrade. These situations can all lead to multiple MBMU devices simultaneously declaring themselves as the master, causing master conflicts and disrupting the upgrade process. Therefore, when multiple MBMU devices declare themselves as the master, it's necessary to ultimately determine one of them as the master, and the rest degrade to slaves. The following examples illustrate how to select one MBMU device as the final master from among multiple MBMU devices declaring themselves as the master.

[0050] In an optional embodiment, if the host receives a broadcast statement from another MBMU device, the method further includes: Send its own device serial number to other MBMU devices that send broadcast statements, and receive other device serial numbers sent by other MBMU devices.

[0051] Compare your own device serial number with the serial numbers of other devices.

[0052] If its own device serial number is the smallest, then it is confirmed as the host.

[0053] If its own device serial number is not the smallest, it will be downgraded to a slave device.

[0054] In this embodiment, the host can be selected directly by comparing device serial numbers. For any MBMU device that claims to be the host, it sends its own device serial number to other MBMU devices that claim to be the host, and receives device serial numbers sent by other MBMU devices.

[0055] The device compares its own device serial number with the serial numbers of other received devices. If it determines that its own device serial number is the smallest among all MBMU devices that claim to be the master, then it confirms itself as the final master. If it determines that its own device serial number is not the smallest, then it is demoted to a slave device.

[0056] Using the above method, a unique host can be quickly and conflict-free determined among multiple MBMU devices that claim to be the host, without the need for an additional central arbitration node.

[0057] It should be noted that the above rule of determining the host based on the device with the smallest serial number is only one example, and the embodiments of the present invention are not limited thereto. In other possible implementations, the host may be determined by the device with the largest serial number, or by the size of the device's MAC address, or by other rules that can uniquely identify a device; all of these fall within the protection scope of the embodiments of the present invention.

[0058] Optionally, if each MBMU device determines that its serial number is the same after comparison, each MBMU device can resend the serial number and compare it again, or re-initiate the host declaration process after a preset delay to avoid deadlock.

[0059] In an optional embodiment, if the host receives a broadcast statement from another MBMU device, the method further includes: Sends the first version information of the full-site upgrade package it holds to other MBMU devices that send broadcast statements, and receives the second version information of the full-site upgrade package sent by other MBMU devices.

[0060] Compare the information from the first version with the information from the second version.

[0061] If the information in the first version is higher than that in the second version, then it is confirmed that it is the host.

[0062] If the information in the first version is lower than that in the second version, then it will be downgraded to a slave.

[0063] If the first version information is equal to the second version information, then send its own device serial number to other MBMU devices that sent the broadcast statement, and receive other device serial numbers sent by other MBMU devices.

[0064] Compare your own device serial number with the serial numbers of other devices.

[0065] If its own device serial number is the smallest, then it is confirmed as the host.

[0066] If its own device serial number is not the smallest, it will be downgraded to a slave device.

[0067] To ensure that the full site upgrade package is the latest version, when a host conflict occurs, any MBMU device that claims to be the host sends the first version information of the full site upgrade package it holds to other MBMU devices that claim to be the host, and receives the second version information of the full site upgrade package sent by other MBMU devices, and compares the first version information with the second version information.

[0068] If it determines that the first version information of the full site upgrade package it holds is higher than the second version information of the full site upgrade package held by other MBMU devices, then it is confirmed that it is the final host.

[0069] If it determines that the first version information of the full site upgrade package it holds is lower than the second version information of the full site upgrade package held by other MBMU devices, it will downgrade itself to a slave device.

[0070] If the first version information and the second version information are the same, then each device sends its own device serial number to other MBMU devices that declare themselves as hosts, and receives device serial numbers sent by other MBMU devices.

[0071] The device compares its own device serial number with the serial numbers of other received devices. If it determines that its own device serial number is the smallest among all MBMU devices that claim to be the master, then it confirms itself as the final master. If it determines that its own device serial number is not the smallest, then it is demoted to a slave device.

[0072] By using the above method, the version information of the full-site upgrade package is used as the primary criterion, and the device serial number is used as the secondary criterion. This allows the device with the latest upgrade package to be selected as the host among multiple MBMU devices that claim to be the host. This ensures that the upgrade process is based on the latest upgrade package for the entire site upgrade, which avoids host conflicts and guarantees the effectiveness and consistency of the upgrade.

[0073] In an optional embodiment, if the host receives a broadcast statement from another MBMU device, the method further includes: Calculate the self-verification value of the full site upgrade package it holds.

[0074] It sends its own checksum to other MBMU devices that send broadcast statements, and receives other checksums from other MBMU devices.

[0075] Perform a consistency comparison between its own check value and other check values.

[0076] If they match, the device sends its own device serial number to other MBMU devices that sent the broadcast statement, and receives other device serial numbers sent by other MBMU devices.

[0077] Compare your own device serial number with the serial numbers of other devices.

[0078] If its own device serial number is the smallest, then it is confirmed as the host.

[0079] If its own device serial number is not the smallest, it will be downgraded to a slave device.

[0080] To ensure the data integrity of the entire site upgrade package, when multiple MBMU devices declare themselves as the host, each MBMU device calculates its own checksum for the entire site upgrade package as its own checksum. This checksum can be calculated using methods such as cyclic redundancy check, MD5 hash algorithm, or secure hash algorithm, and is used to uniquely identify and verify the data integrity of the entire site upgrade package.

[0081] It sends its own checksum to other MBMU devices that claim to be the host, and receives other checksums from other MBMU devices. It then performs a consistency comparison between its own checksum and the received checksums.

[0082] If the self-check value is consistent with other check values, it means that the MBMU devices that claim to be hosts have the same content in the whole site upgrade package.

[0083] At this point, it further sends its own device serial number to other MBMU devices that claim to be the host, and receives device serial numbers sent by other MBMU devices, and compares its own device serial number with the received device serial numbers.

[0084] If a device determines that its own serial number is the smallest among all MBMU devices that claim to be the master, then it is confirmed as the final master. If it determines that its own serial number is not the smallest, then it is demoted to a slave device.

[0085] If a device's own checksum is inconsistent with other checksums, it indicates that the MBMU devices claiming to be the master possess different full-site upgrade package contents. In this case, the MBMU device with the latest version information can continue to participate in the master competition, while the MBMU device with the lower version information is downgraded to a slave. Alternatively, if the checksums are inconsistent, the device with the latest version information corresponding to the checksum is identified as the master.

[0086] Alternatively, if its own checksum is inconsistent with other checksums, an alarm will be issued and the upgrade will be stopped.

[0087] Using the above method, when multiple MBMU devices declare themselves as the master, the checksums of the full-site upgrade packages are exchanged and compared to first confirm whether the upgrade package content held by each device is consistent. If they are consistent, a unique master is identified by the device serial number, ensuring that each slave device receives the exact same upgrade package from the master, avoiding upgrade version confusion. If they are inconsistent, the MBMU device with the higher version information becomes the master, ensuring that the entire energy storage power station is upgraded according to the latest version.

[0088] In an optional embodiment, the site-wide upgrade package includes an upgrade authorization token.

[0089] Before sending the full-site upgrade package to each slave device, the method also includes: The upgrade authorization token is used for the first level of identity authentication based on the preset public key.

[0090] Correspondingly, if the first-level identity authentication is successful, the upgrade authorization token will be issued to each slave device.

[0091] Receive upgrade authorization verification information from each slave device; the upgrade authorization verification information is obtained by each slave device verifying the upgrade authorization token based on its own preset public key copy; the upgrade authorization verification information includes upgrade authorization verification pass information and upgrade authorization failure information.

[0092] The percentage of verified information in the statistical upgrade authorization verification information.

[0093] Correspondingly, if the proportion is greater than the preset proportion, the entire site upgrade package will be sent to each slave machine.

[0094] If the proportion is not greater than the preset proportion, the full-site upgrade package will not be sent to each slave machine, and a warning will be issued.

[0095] In the current solution, a full-site upgrade can be triggered simply by inserting the local storage medium into any MBMU device or by remotely issuing the upgrade command. However, in high-security scenarios like energy storage power stations, if maintenance personnel mistakenly bring unstable local storage media from the test environment into the field, or if internal interfaces are accessed by unauthorized personnel, it could lead to a complete BMS outage. To address this issue, this embodiment performs a comprehensive security check on the full-site upgrade package.

[0096] The method provided in this embodiment includes two levels of verification: the first level is the verification of the host, and the second level is the verification of each slave device. Specifically: The host first decrypts the upgrade authorization token using its own preset public key, extracting the operator's identity ID and authorization validity period from the token. It then verifies whether the current time is within the authorization validity period and checks if the operator's identity ID exists in the host's locally stored list of legitimate operators.

[0097] If the current time is within the authorization period and the operator's identity ID exists in the list of legitimate operators stored locally on the host, then the first level of identity authentication is considered successful.

[0098] After that, the host will issue the upgrade authorization token to each slave device.

[0099] Each slave device stores a local copy of a preset public key. Each slave device decrypts the upgrade authorization token using its own preset public key copy, extracting the operator's identity ID and authorization validity period from the token. It verifies whether the current time is within the authorization validity period and checks if the operator's identity ID exists in the slave device's locally stored list of legitimate operators.

[0100] If the current time is within the authorization validity period and the operator's identity ID exists in the list of legitimate operators stored locally on the slave device, the upgrade authorization verification is deemed successful; otherwise, it is deemed unsuccessful.

[0101] The host receives and counts the percentage of successfully verified upgrade authorization verification messages sent by the slave.

[0102] When the proportion is greater than the preset proportion, such as one-half or two-thirds, the full-site upgrade package will be sent to each slave machine for subsequent upgrades; otherwise, the full-site upgrade package will not be sent to each slave machine, and a warning will be issued to stop the upgrade.

[0103] This method effectively ensures the security of the entire site upgrade.

[0104] In an optional embodiment, before sending the full-site upgrade package to each slave device, the method further includes: An upgrade preparation command is sent to each slave device; the upgrade preparation command is used to instruct each slave device to delete the upgrade package it already holds locally.

[0105] In this embodiment, the host receives and stores the full-site upgrade package in the local storage medium when it detects the insertion of the local storage medium. Even after the multi-host contention is completed, the MBMU device, downgraded to a slave, still stores the full-site upgrade package. To prevent version inconsistencies, the host can send an upgrade preparation command to each slave before sending the full-site upgrade package. This command instructs each slave to clear any remaining historical upgrade packages or temporary data from its local cache to free up storage space and ensure a clean upgrade environment. Upon receiving the upgrade preparation command, each slave checks whether it holds a historical upgrade package. If so, it deletes or overwrites the historical upgrade package and returns a ready response to the host.

[0106] After receiving the ready response, the host sends the full-site upgrade package to each slave device.

[0107] In an optional embodiment, before sending the full-site upgrade package to each slave device, the method further includes: Send the host version of the full-site upgrade package to each slave machine.

[0108] Receive version comparison information from each slave device; the version comparison information is used to indicate whether the host version of the full site upgrade package is consistent with the slave version of the full site upgrade package held by each slave device.

[0109] Accordingly, the full-site upgrade package will be sent to each slave device, including: Send a full-site upgrade package to each slave device where the version comparison information is inconsistent.

[0110] By using the above method, when the full-site upgrade package held by each slave device is consistent with the full-site upgrade package to be distributed by the master device, each slave device does not need to delete its existing full-site upgrade package, and the master device does not need to distribute the full-site upgrade package to the slave device, which can save upgrade time.

[0111] In an optional embodiment, after sending the full-site upgrade package to each slave device, the method further includes: Receive upgrade package verification information sent by each slave device; wherein, the upgrade package verification information is generated by the slave devices through the exchange of verification values ​​for consistency comparison, and is used to indicate whether the full-site upgrade packages received by each slave device are consistent.

[0112] If there are slave devices with inconsistent verification values ​​in the upgrade package verification information, the entire upgrade package will be resent to that slave device.

[0113] Alternatively, resend the full-site upgrade package to the slave device that did not report the upgrade package verification information.

[0114] In this embodiment, the upgrade packages of each slave device are the same. Therefore, any two slave devices can verify whether the received full-site upgrade packages are consistent to determine whether the received full-site upgrade packages are erroneous or corrupted.

[0115] The upgrade package verification information includes consistency information and inconsistency signals. Accordingly, after sending the full-site upgrade package to each slave, the host receives the upgrade package verification information sent by each slave. The host determines whether there is any inconsistency in the received upgrade package verification information; if so, it resends the full-site upgrade package to the slave that sent the inconsistency information.

[0116] Alternatively, the upgrade package verification information is sent by each slave device that has a consistent verification, while slave devices with inconsistent verification do not send it. Accordingly, after sending the full-site upgrade package to each slave device, the host receives the upgrade package verification information from each slave device. Based on the received upgrade package verification information, the host identifies the slave devices that have not reported upgrade package verification information and resends the full-site upgrade package to those slave devices.

[0117] In an optional implementation, the upgrade package verification information also includes verification information for each SBMU and BMU device. The verification information for each SBMU and BMU device is sent to the host through its corresponding slave device. The host directly receives the verification information from the SBMU and BMU devices on its respective tributary.

[0118] The host determines whether the upgrade package received by each SBMU and BMU device is correct based on the verification information received from each SBMU and BMU device. If not, the host resends the full-site upgrade package to the slave device corresponding to the SBMU or BMU device with the incorrect upgrade package.

[0119] The full-site upgrade package sent from the host to each slave device includes the host verification code for the upgrade package corresponding to each device; the verification information for each SBMU device and BMU device is determined in the following way: Each SBMU or BMU device calculates its own checksum based on the received upgrade package, compares its own checksum with the corresponding host checksum to determine whether the received upgrade package is correct, generates verification information based on the comparison result, and sends the verification information to the host through its corresponding slave device.

[0120] In an optional embodiment, a hardware compatibility list is embedded in the sub-upgrade package of each device in the MBMU layer, SBMU layer, and BMU layer. Before issuing upgrade commands to each slave device, the method also includes: Receive upgrade package matching information sent by each slave device; wherein, the upgrade package matching information is used to characterize the matching result between the hardware information of each device in the MBMU layer, SBMU layer and BMU layer and the hardware compatibility list in the corresponding sub-upgrade package.

[0121] Accordingly, upgrade instructions are issued to each slave device, including: Send upgrade commands to each slave device whose matching result is consistent; Send an upgrade prohibition command to each slave device whose matching result is inconsistent.

[0122] Given the long construction cycle and frequent expansion of energy storage power stations, devices at the same level often have inconsistent hardware versions. When the issued upgrade package is incompatible with the device's hardware, a forced upgrade may prevent the device from automatically rolling back. If this happens, the device needs to be removed on-site, but on-site replacement is extremely costly.

[0123] To avoid this situation, embodiments of the present invention embed a hardware compatibility list for each device within the upgrade package for each device. This hardware compatibility list includes at least one or more of the following: The device model information, hardware version information, and hardware signature range that match the sub-upgrade package.

[0124] After receiving its corresponding sub-upgrade package, each device will match and verify its own hardware information, such as hardware identity, with the hardware compatibility list in the sub-upgrade package.

[0125] If all the information matches and is verified, a matching message is generated; otherwise, a mismatch message is generated. Based on the matching result, the upgrade package matching information is sent from the corresponding slave device to the master device.

[0126] The host reads the specific matching results from the upgrade package matching information. Devices that match are allowed to upgrade, while devices that do not match are prohibited from upgrading, in order to ensure device security.

[0127] Optionally, the hardware identity may include the device model, hardware version number, and core chip ID. Correspondingly, matching and verifying its own hardware information against the hardware compatibility list in the sub-upgrade package may include: Each check verifies whether the device model matches, whether the hardware version number falls within the version range in the hardware version information, and whether the core chip ID falls within the range of hardware signature codes.

[0128] When the device model matches, the hardware version number falls within the version range of the hardware version information, and the core chip ID falls within the range of hardware feature codes, the matching verification is deemed successful, and matching information is generated.

[0129] Otherwise, the matching verification is deemed to have failed, and a mismatch message is generated.

[0130] Similarly, during this process, the host, as well as each SBMU and BMU device on the branch where the host is located, also perform the above matching and verification steps.

[0131] The matching and verification process is only for illustrative purposes and does not require that the above three conditions be met during matching. The specific matching items are determined based on the specific contents of the hardware compatibility list. What is certain is that the hardware identity must match all the contents in the hardware compatibility list before subsequent upgrades can be performed.

[0132] The upgrade process has been described above from the host side. The upgrade method provided by this embodiment of the invention is now described below from the slave side. Figure 3 A flowchart illustrating the upgrade method applied to the slave side is shown. For example... Figure 3 As shown, the method may include: Step 210: Receive the full-site upgrade package sent by the host; the full-site upgrade package includes upgrade packages for each device in the MBMU layer, SBMU layer and BMU layer.

[0133] Corresponding to step 120, each slave device reports its own information, as well as the device information of the SBMU and BMU devices on its own branch, to the host so that the host can determine the network topology of each slave device and the SBMU and BMU devices on its own branch.

[0134] Based on the network topology, each slave device receives a full-site upgrade package sent by the host through a preset communication link.

[0135] Step 220: Based on the branch where it is located, parse and extract the slave upgrade package from the full-site upgrade package. The slave upgrade package includes the upgrade package of the slave itself, as well as the upgrade packages corresponding to the SBMU and BMU devices on the branch where the slave is located.

[0136] Based on the network topology, the slave device identifies the SBMU and BMU devices on its own branch. It then parses and extracts its own upgrade package, as well as the upgrade packages for the SBMU and BMU devices on its own branch, from the full-site upgrade package.

[0137] After retrieving the upgrade package from the slave device, the upgrade package is verified to confirm its completeness and correctness.

[0138] Step 230: Send the upgrade package corresponding to the SBMU and BMU devices on the branch where the slave device is located to the SBMU and BMU devices on the branch where it is located, so as to upgrade itself and the SBMU and BMU devices on the branch where it is located.

[0139] After the slave device confirms that the extracted upgrade package is correct, it sends the corresponding upgrade package to the SBMU and BMU devices on its own branch, and sends the verification information of its own upgrade package by the SBMU and BMU devices on its own branch to the host.

[0140] The upgrade process begins upon receiving an upgrade command from the host or after a preset time.

[0141] Similarly, in this process, the host parses and extracts its own host upgrade package from the full-site upgrade package, and then distributes the upgrade packages corresponding to the SBMU and BMU devices on the branch where the host is located to the corresponding SBMU and BMU devices respectively.

[0142] As can be seen, in this embodiment of the invention, one MBMU device is designated as the master in the MBMU layer of the BMS device, and the remaining MBMU devices are slaves. During upgrades, each slave receives a full-site upgrade package from the master, parses and extracts its own upgrade packages, as well as those of the SBMU and BMU devices on its own branch, and then distributes the upgrade packages to the SBMU and BMU devices on its own branch. Throughout the entire process, the slaves do not need to communicate with other local storage media or remote control devices. Compared to traditional manual operations, this is more efficient and reliable.

[0143] The method applied to a slave device provided by the embodiments of the present invention will be described in detail below with reference to some optional embodiments.

[0144] In an optional embodiment, after receiving the site-wide upgrade package from the host, the method further includes: The system calculates a checksum based on the received full-site upgrade package and exchanges checksums with other slave machines for consistency comparison.

[0145] Based on the consistency comparison results, upgrade package verification information is generated and sent to the host.

[0146] If the consistency comparison result is inconsistent, then the system will re-receive the full-site upgrade package sent by the host.

[0147] Alternatively, if the consistency comparison result is consistent, upgrade package verification information is generated and sent to the host.

[0148] If the consistency comparison result is inconsistent, no upgrade package verification information will be generated, and the full-site upgrade package issued by the host will be received again.

[0149] Each slave device has the same upgrade package. Therefore, any two slave devices can verify whether the received full-site upgrade packages are consistent to determine whether the received full-site upgrade packages are incorrect or corrupted.

[0150] Each slave device performs the following steps: The system calculates a checksum based on the received full-site upgrade package, then identifies the closest slave device based on the network topology, and exchanges checksums with the closest slave device for consistency comparison.

[0151] Regardless of whether the comparison results are consistent, an upgrade package verification message is sent to the host. Specifically: Upgrade package verification information is generated based on the consistency comparison results and sent to the host. This verification information includes both consistent and inconsistent comparisons.

[0152] Correspondingly, if the consistency comparison result is inconsistent, the system will re-receive the full-site upgrade package sent by the host.

[0153] Alternatively, in an optional embodiment, the slave device only sends upgrade package verification information to the master device when the comparison is consistent.

[0154] Correspondingly, if the consistency comparison result is consistent, upgrade package verification information is generated and sent to the host.

[0155] If the consistency comparison result is inconsistent, no upgrade package verification information will be generated, and the full-site upgrade package issued by the host will be received again.

[0156] As can be seen, this embodiment can determine whether the full-site upgrade package it receives is erroneous or damaged by comparing and verifying each slave device.

[0157] In an optional embodiment, the slave device is determined in the following way: After not detecting the insertion of local storage media and receiving a broadcast declaration, it determines itself to be a slave device.

[0158] Similar to the logic for determining whether it is a master, for any MBMU device, if it does not detect the insertion of local storage media and receives a broadcast declaration, it determines that it is a slave.

[0159] If the MBMU device detects the insertion of local storage media and receives a broadcast declaration, the method further includes: Send its own device serial number to other MBMU devices that send broadcast statements, and receive other device serial numbers sent by other MBMU devices.

[0160] Compare your own device serial number with the serial numbers of other devices.

[0161] If its own device serial number is the smallest, it will upgrade itself to the host.

[0162] If its own device serial number is not the smallest, then it is confirmed that it is a slave device.

[0163] Alternatively, in an optional embodiment, if the MBMU device detects the insertion of a local storage medium and receives a broadcast declaration, the method further includes: Sends the first version information of the full-site upgrade package it holds to other MBMU devices that send broadcast statements, and receives the second version information of the full-site upgrade package sent by other MBMU devices.

[0164] Compare the information from the first version with the information from the second version.

[0165] If the information in the first version is superior to that in the second version, then it will be upgraded to the host.

[0166] If the information in the first version is lower than that in the second version, then it is confirmed that it is a slave device.

[0167] If the first version information is equal to the second version information, then send its own device serial number to other MBMU devices that sent the broadcast statement, and receive other device serial numbers sent by other MBMU devices.

[0168] Compare your own device serial number with the serial numbers of other devices.

[0169] If its own device serial number is the smallest, it will upgrade itself to the host.

[0170] If its own device serial number is not the smallest, then it is confirmed that it is a slave device.

[0171] Alternatively, in an optional embodiment, if the MBMU device detects the insertion of a local storage medium and receives a broadcast declaration, the method further includes: It sends its own checksum to other MBMU devices that send broadcast statements, and receives other checksums from other MBMU devices.

[0172] Perform a consistency comparison between its own check value and other check values.

[0173] If they match, the device sends its own device serial number to other MBMU devices that sent the broadcast statement, and receives other device serial numbers sent by other MBMU devices.

[0174] Compare your own device serial number with the serial numbers of other devices.

[0175] If its own device serial number is the smallest, it will upgrade itself to the host.

[0176] If its own device serial number is not the smallest, then it is confirmed that it is a slave device.

[0177] By using the methods described above, host conflicts that could lead to upgrade failures can be avoided.

[0178] In an optional embodiment, the site-wide upgrade package includes an upgrade authorization token.

[0179] Before receiving the site-wide upgrade package from the host, the method also includes: Receive upgrade authorization token.

[0180] The upgrade authorization token is verified based on a copy of its own preset public key, upgrade authorization verification information is generated, and the upgrade authorization verification information is sent to the host.

[0181] In this embodiment, when the full-site upgrade package undergoes a first-level verification and passes the verification, each slave device receives the upgrade authorization token issued by the host and performs a second-level verification on the upgrade authorization token.

[0182] The secondary verification process is similar to the primary verification process. Each slave device stores a local copy of a preset public key. Each slave device decrypts the upgrade authorization token using its own preset public key copy, extracting the operator's identity ID and authorization validity period from the upgrade authorization token. It then verifies whether the current time is within the authorization validity period and checks whether the operator's identity ID exists in the list of legitimate operators stored locally on the slave device.

[0183] If the current time is within the authorization validity period and the operator's identity ID exists in the list of legitimate operators stored locally on the slave device, the upgrade authorization verification is considered successful; otherwise, it is considered unsuccessful. Accordingly, if the upgrade authorization verification is successful, the sent upgrade authorization verification message will be "verified successfully"; if it is considered unsuccessful, the sent upgrade authorization verification message will be "verified unsuccessfully".

[0184] After sending the upgrade authorization verification information to the host, wait for the host to determine whether to upgrade. If the host determines that the upgrade is allowed, receive the full-site upgrade package issued by the host.

[0185] In an optional embodiment, before receiving the site-wide upgrade package from the host, the method further includes: Receive upgrade preparation instructions from the host.

[0186] Check if you have the full site update package.

[0187] If so, delete any full-site upgrade packages that you already own.

[0188] Considering that some of the slave devices in the MBMU were demoted from the master to the slave, and these MBMU devices already have the corresponding full-site upgrade package stored, in order to prevent version conflicts or upgrade failures after receiving the full-site upgrade package sent by the master, each slave device first receives the upgrade preparation command sent by the master before receiving the full-site upgrade package sent by the master, in order to determine whether it has stored the full-site upgrade package. If it does, it deletes it and returns a ready response to the master.

[0189] Alternatively, in an optional embodiment, before receiving the site-wide upgrade package from the host, the method further includes: The host version that receives the site-wide upgrade package from the host server; Determine whether the slave version and master version of the full site upgrade package you possess are consistent; If they match, a version consistency message is sent to the host, and the host's full-site upgrade package is not accepted.

[0190] By using the above method, when the full-site upgrade package held by each slave device is consistent with the full-site upgrade package to be issued by the master device, each slave device does not need to delete its existing full-site upgrade package, and the master device does not need to issue a full-site upgrade package to the slave device, which can save upgrade time.

[0191] In an optional embodiment, a hardware compatibility list is embedded in the sub-upgrade package of each device in the MBMU layer, SBMU layer, and BMU layer. After receiving the site-wide upgrade package from the host, the method also includes: It matches its own hardware information with the hardware compatibility list in the sub-upgrade package to generate slave upgrade package matching information; and receives branch upgrade package matching information from each SBMU device and each BMU device on its own path.

[0192] The slave upgrade package matching information and the tributary upgrade package matching information will be sent to the host as upgrade package matching information.

[0193] In this embodiment, the hardware compatibility list includes one or more of the following data that match the sub-upgrade package: device model information, hardware version information, and hardware signature range.

[0194] After receiving its corresponding sub-upgrade package, each slave device matches and verifies its own hardware information, such as hardware identification, with the hardware compatibility list in the sub-upgrade package. If all the information matches, a matching information is generated; otherwise, a mismatch information is generated. Based on the matching results, slave device upgrade package matching information is generated.

[0195] At the same time, each SBMU device and each BMU device also perform the above steps to generate tributary upgrade package matching information and send the tributary upgrade package matching information to the corresponding slave device.

[0196] The slave device generates upgrade package matching information based on the slave upgrade package matching information and the tributary upgrade package matching information, and sends it to the master device.

[0197] For each slave device, if there is a mismatch in the upgrade package matching information it sends, the entire branch will not be upgraded. If there is no mismatch in the upgrade package matching information it sends, it will perform the upgrade upon receiving the upgrade command from the master device.

[0198] The following is combined Figure 4 This document provides a comprehensive overview of the steps performed by the host and each slave device during the upgrade process, such as... Figure 4 As shown, the full-site BMS equipment upgrade process is as follows: After the BMS device starts up, multiple MBMU devices compete to determine one MBMU device as the master, and the remaining MBMU devices as slaves. The MBMU device that has determined itself as the master sends a declaration to the other MBMU devices that have confirmed themselves as slaves.

[0199] The host receives the local full-site upgrade package, performs the first level of authentication on the full-site upgrade package, and after successful authentication, performs the second level of authentication on the full-site upgrade package through each slave device.

[0200] After successful Level 2 authentication, the host sends an upgrade preparation command to each slave device. Each slave device accepts the upgrade preparation command, checks and deletes any existing historical upgrade packages it holds locally, and after deletion, each slave device sends a ready response back to the host.

[0201] After receiving the ready response, the host sends the full-site upgrade package to each slave. After receiving the full-site upgrade package, each slave exchanges checksums with other slaves for consistency comparison to verify the upgrade package, and reports the comparison results to the host. If the verification is inconsistent, the host will re-receive the full-site upgrade package.

[0202] Next, each slave and master machine, based on its own branch, parses and extracts the sub-upgrade packages corresponding to itself and the SBMU and BMU devices on its own branch from the full-site upgrade package, and sends them to the corresponding SBMU and BMU devices respectively.

[0203] After the sub-upgrade package is distributed, the host and the SBMU and BMU devices on the host's branch, as well as each slave device and the SBMU and BMU devices on its branch, perform compatibility matching verification based on the received sub-upgrade package. Devices that match are upgraded with firmware, while devices that do not match are not upgraded.

[0204] This method completes the upgrade of the entire site's BMS equipment.

[0205] After the upgrade is complete, each slave device sends the upgrade result to the master device. The master device generates log information based on its own upgrade result and the upgrade results of each slave device.

[0206] In summary, this embodiment of the invention enables local upgrades in scenarios where remote upgrades are not possible by setting up master-slave configurations in the MBMU device, with the designated master sending full-site upgrade packages to each slave device. Furthermore, this process eliminates the need for maintenance personnel to import the full-site upgrade packages to each MBMU device individually, significantly improving upgrade efficiency.

[0207] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present invention.

[0208] In an optional embodiment, the present invention also provides an MBMU device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the method described above.

[0209] In an optional embodiment, this invention also provides a BMS device, including multiple MBMU devices as described above; each MBMU device includes a master unit and multiple slave units. For ease of description and brevity, the above-described division of functional modules / units is used as an example. In practical applications, the above functions can be assigned to different functional modules / units as needed. The above modules / units can be implemented in hardware, software, or a combination of both.

[0210] In the above embodiments, the descriptions of each embodiment have their own emphasis. Parts not detailed or described in a particular embodiment can be referred to in the relevant descriptions of other embodiments. Unless otherwise specified or in conflict with logic, the terminology and / or descriptions between different embodiments are consistent and can be referenced interchangeably. Technical features in different embodiments can be combined to form new embodiments based on their inherent logical relationships.

[0211] The above-described embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit it. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be included within the protection scope of the present invention.

Claims

1. A method for upgrading the entire BMS equipment of an energy storage power station, characterized in that, The battery management system (BMS) device includes multiple master control units (MBMUs), each comprising a master unit and multiple slave units. The method is applied to the host, and the method includes: Receive a local full-site upgrade package; wherein, the full-site upgrade package includes sub-upgrade packages for each device in the MBMU layer, the SBMU layer, and the BMU layer; The full-site upgrade package is sent to each slave device, so that each slave device can parse and extract the slave upgrade package from the full-site upgrade package based on its own branch, and send the sub-upgrade packages corresponding to the SBMU and BMU devices on its own branch to the corresponding SBMU and BMU devices for upgrade. The slave upgrade package includes a sub-upgrade package for the slave itself, as well as sub-upgrade packages corresponding to the SBMU and BMU devices on the branch where the slave is located.

2. The method for upgrading the entire BMS equipment of an energy storage power station according to claim 1, characterized in that, After sending the full-site upgrade package to each slave device, the method further includes: Receive upgrade package verification information sent by each slave device; wherein, the upgrade package verification information is generated by the slave devices through a consistency comparison by exchanging verification values, and is used to indicate whether the full-site upgrade packages received by each slave device are consistent; If there is a slave device with an inconsistent verification value in the upgrade package verification information, the full-site upgrade package will be resent to that slave device. Alternatively, the full-site upgrade package can be resent to slave devices that have not reported upgrade package verification information.

3. The method for upgrading the entire BMS equipment of an energy storage power station according to claim 1, characterized in that, The host is determined in the following way: The MBMU device that detects the insertion of the local storage medium confirms itself as the host and sends a broadcast declaration to other MBMU devices; wherein the local storage medium contains the full-site upgrade package.

4. The method for upgrading the entire BMS equipment of an energy storage power station according to claim 1, characterized in that, Before sending the full-site upgrade package to each slave device, the method further includes: An upgrade preparation command is issued to each slave device; wherein the upgrade preparation command is used to instruct each slave device to delete the full-site upgrade package that it already holds locally.

5. A method for upgrading the entire BMS equipment of an energy storage power station, characterized in that, The BMS device includes one master and multiple slave MBMU devices. The method is applied to any one of the plurality of slave devices, and the method includes: Receive the full-site upgrade package sent by the host; wherein the full-site upgrade package includes sub-upgrade packages for each device in the MBMU layer, SBMU layer and BMU layer; Based on the branch it is located on, the slave upgrade package is parsed and extracted from the full-site upgrade package. The slave upgrade package includes the slave's own sub-upgrade package, as well as the sub-upgrade packages corresponding to the SBMU and BMU devices on the branch where the slave is located. The sub-upgrade package corresponding to the SBMU and BMU devices on the branch where the slave device is located is sent to the SBMU and BMU devices on the branch where it is located, so as to upgrade itself and the SBMU and BMU devices on the branch where it is located.

6. The method for upgrading the entire BMS equipment of an energy storage power station according to claim 5, characterized in that, After receiving the site-wide upgrade package from the receiving host, the method further includes: The verification value is calculated based on the received full-site upgrade package, and the verification value is exchanged with other slave machines for consistency comparison. Based on the consistency comparison results, upgrade package verification information is generated and sent to the host; If the consistency comparison result is inconsistent, then the full-site upgrade package sent by the host will be received again; Alternatively, if the consistency comparison result is consistent, upgrade package verification information is generated and the upgrade package verification information is sent to the host; If the consistency comparison result is inconsistent, no upgrade package verification information will be generated, and the full-site upgrade package issued by the host will be received again.

7. The method for upgrading the entire BMS equipment of an energy storage power station according to claim 5, characterized in that, The slave device is determined in the following way: After not detecting the insertion of local storage media and receiving a broadcast declaration, it determines itself to be a slave device.

8. The method for upgrading the entire BMS equipment of an energy storage power station according to claim 5, characterized in that, Before receiving the site-wide upgrade package from the receiving host, the method further includes: Receive the upgrade preparation command issued by the host; Check if you have the full site update package; If so, delete any full-site upgrade packages that you already own.

9. An MBMU device, characterized in that, It includes a memory and a processor, the memory storing a computer program, and the processor executing the computer program to implement the method as described in any one of claims 1 to 4, or to implement the method as described in any one of claims 5 to 8.

10. A BMS device, characterized in that, It includes multiple MBMU devices as described in claim 9; the MBMU device includes a master and multiple slave devices.

Images