A method and system for upgrading a master-slave computer in a business storage system

Abstract

The application provides a kind of business storage system master-slave machine parallel machine upgrade method and system, it is related to business storage system intelligent upgrading technical field, the method includes that host receives cloud platform OTA upgrade command, downloads firmware upgrade package and verifies legality;Notify slave synchronous upgrade information and enter upgrade state;Host fragmented transmission upgrade package, slave verification storage, host regularly inquires reception state;Check slave upgrade package integrity;Master-slave machine synchronous execution upgrade;After upgrade, check version consistency, consistent then normal operation, otherwise enter fault state.The system includes host module, slave module, communication module and upgrade management module.The application realizes efficient, safe, compatible online parallel machine upgrade, greatly shortens time consumption, guarantees power supply continuity, reduces cost.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of intelligent upgrading of industrial and commercial storage systems, and in particular to a master-slave machine parallel upgrading method and system for industrial and commercial storage systems. BACKGROUND

[0002] Industrial and commercial energy storage (industrial and commercial storage) systems usually include a battery management system (BMS) and an energy management system (EMS). In a multi-machine parallel operation scenario, different batches or models of energy storage devices often cannot be stably connected in parallel due to inconsistent system versions. With the increasing penetration rate of industrial and commercial energy storage, the system needs to support the rapid, safe, and compatible remote upgrading of a large number of devices, and traditional upgrading methods have many limitations.

[0003] Currently, the industry mainly faces the following pain points in the upgrading of industrial and commercial storage systems: first, the upgrading efficiency is low, and traditional methods require manual connection of slave devices (such as EMS and BMS), which is tedious and time-consuming, especially for distributed energy storage cabinets, with high on-site upgrade costs; second, the safety is insufficient, and existing Over-The-Air (OTA) upgrade protocols generally lack multi-layer verification mechanisms, are vulnerable to man-in-the-middle attacks, and have the risk of malicious firmware injection; third, the compatibility is poor, and the interface protocols of heterogeneous devices such as power conversion systems (PCS) and BMS from different manufacturers are not unified, requiring the master to adapt to multiple communication protocols, resulting in a high failure rate of upgrades; fourth, the system needs to be shut down for operation during the upgrading process, causing a long power outage, which seriously affects the system's operating income.

[0004] In existing technologies, although some upgrading solutions use one-way handshake verification mechanisms, they still do not solve the problem of power continuity of slave devices during upgrading, and data loss often occurs during the upgrading process. In addition, the method of distributing upgrade packages through HTTP protocols lacks a master-slave state coordination mechanism, and can easily cause system shock during multi-machine parallel upgrading. The "one-key upgrade" function introduced by some manufacturers only supports devices of the same model, and in actual applications, the high failure rate of upgrades (up to 30%) caused by differences in BMS versions often cannot meet the needs of parallel upgrading of multiple models and batches.

[0005] Therefore, there is an urgent need for an industrial and commercial storage system master-slave machine parallel upgrading method and system that can achieve efficient, safe, and compatible online non-stop upgrading to meet the growing needs of industrial and commercial energy storage system iteration and upgrading. SUMMARY

[0006] To this end, the embodiment of the present application provides a kind of industrial and commercial storage system master-slave machine parallel machine upgrade method and system, to solve the problems of low efficiency, poor security, compatibility is insufficient and the power supply is interrupted due to upgrade process needs to be stopped in prior art.

[0007] To solve the above problems, the embodiment of the present application provides an industrial and commercial storage system master-slave machine parallel machine upgrade method, which comprises:

[0008] S1: the host receives the OTA upgrade command issued by the cloud platform, and the OTA upgrade command contains the server address and the total CRC check value of the upgrade package; after the host receives the OTA upgrade command, it enters the upgrade state, connects the specified server to download the firmware upgrade package, the firmware upgrade package contains the firmware header and the upgrade package, and stores the firmware upgrade package and the total CRC check value of the upgrade package to the local backup storage area according to the device type identification of the firmware header;

[0009] S2: the host reads the upgrade package and the total CRC check value of the upgrade package in the local backup storage area, calculates the total CRC calculation value of the upgrade package by CRC algorithm, compares whether the total CRC check value of the upgrade package is consistent with the total CRC calculation value of the upgrade package, if consistent, it is determined that the upgrade package is legal and the check is passed, and S3 is executed, otherwise, the upgrade state is exited and the upgrade is ended;

[0010] S3: the host notifies all slaves to enter the upgrade state, synchronizes the total size of the upgrade package and the total CRC check value of the upgrade package to the slave, and the slave enters the upgrade state based on the master-slave upgrade state coordination mechanism, and saves the total size of the upgrade package and the total CRC check value of the upgrade package to the cache area;

[0011] S4: the host uses a fragmentation transmission method to split the upgrade package into multiple small packages according to a preset size, and sends them to the slave one by one; the slave calculates and checks the CRC value of the small package after receiving it, and stores it to the local backup storage area if the check is passed, without immediate reply to the host; the host queries the slave reception state in address order after sending a preset number of small packages, and if all slaves receive normally, it continues to send the remaining small packages, otherwise it notifies the slave to exit the upgrade state and ends the upgrade;

[0012] S5: the host queries the total CRC calculation value of the upgrade package in the local backup storage area of the slave one by one; the slave calculates the total CRC calculation value of the local upgrade package by CRC algorithm and feeds back to the host; the host compares the total CRC calculation value of the upgrade package fed back by all slaves with the total CRC check value of the upgrade package, if they are consistent, S6 is executed; otherwise, all slaves are notified to exit the upgrade state and the upgrade is ended;

[0013] S6: the host informs all slaves to perform upgrade, and the slave performs upgrade on the corresponding device according to the device type identifier of the locally stored firmware header; after the host informs all slaves to perform upgrade, the device type identifier of the locally stored firmware header is judged to perform upgrade on the corresponding device of the host;

[0014] S7: after the host and slave upgrade is completed, the initialization state is entered, and then the parallel machine process is entered; the host queries all slave version information based on the version checking method, checks the consistency of the host and slave versions, if consistent, the system enters the normal operation state, if inconsistent, the system enters the fault state.

[0015] Preferably, in step S1, the upgrade package total CRC check value is generated by using the CRC-32 algorithm, the firmware header contains the version number, the device type identifier and the system model, and the host preliminarily screens the storage path of the adaptive upgrade package through the system model of the firmware header.

[0016] Preferably, in step S4, the size of the small package is 256 bytes to 1024 bytes, each small package is attached with a small package CRC check value generated based on the CRC-16 algorithm, and the slave first verifies the integrity of the small package through the small package CRC check value after receiving the small package, and then performs the storage operation.

[0017] Preferably, in step S4, when the fragmentation transmission check fails, the host records the number of the current error fragment, starts the breakpoint resume transmission protocol, and only reissues the error fragment; if the same fragment fails for three times in succession, it is determined that the upgrade transmission is abnormal, the host informs all slaves to exit the upgrade state, and ends this upgrade.

[0018] Preferably, in step S7, the version checking method is specifically: the host polls all slaves through the MODBUS RTU protocol, obtains the device ID, system model and version number of the slave, compares the system model and version number of the slave with the system model and version number of the host itself, and if the system model of all slaves matches the host and the version number is consistent, it is determined that the version checking is passed.

[0019] Preferably, the method further comprises:

[0020] The host detects the online state of the slave in a timely manner, and if the slave does not respond within a specified time, it is determined to be offline, the host will inform all slaves to exit this upgrade, and end this upgrade.

[0021] Preferably, the method further comprises:

[0022] The slave actively exits the upgrade state when it does not receive the host instruction within a predetermined time.

[0023] The embodiment of the present application also provides a master-slave machine parallel upgrading system of a commercial and industrial storage system, which is used for implementing the master-slave machine parallel upgrading method of the commercial and industrial storage system, and specifically comprises the following steps:

[0024] The master module is used for receiving an OTA upgrading command issued by a cloud platform, downloading a firmware upgrading package from a specified server and storing the firmware upgrading package according to a firmware header device type identifier, verifying legality of the upgrading package, coordinating all slaves to enter an upgrading state based on a master-slave machine upgrading state coordination mechanism, performing slice transmission and slave state query, triggering master-slave machine upgrading operations, and verifying consistency of master-slave machine versions.

[0025] The slave module is used for receiving an upgrading state notification and an upgrading package packet of the master module, verifying and storing a CRC value of the packet, feeding back a receiving state and an upgrading package total CRC calculation value, performing corresponding device upgrading according to an instruction of the master module, and participating in version verification in a parallel process.

[0026] The communication module is used for realizing data transmission between the master module and the slave module.

[0027] The upgrading management module is used for managing generation, distribution, verification and command issuing of the upgrading package.

[0028] The embodiment of the present application also provides an electronic device, which comprises a processor, a memory and a bus system, the processor and the memory are connected through the bus system, the memory is used for storing instructions, and the processor is used for executing the instructions stored in the memory to implement the master-slave machine parallel upgrading method of the commercial and industrial storage system.

[0029] The embodiment of the present application also provides a computer storage medium, which stores a computer software product, the computer software product comprises a plurality of instructions, and is used for enabling a computer device to execute the master-slave machine parallel upgrading method of the commercial and industrial storage system.

[0030] From the above technical solutions, the present application has the following beneficial effects:

[0031] (1) The upgrading efficiency is significantly improved: compared with the traditional manual upgrading method, the present application receives the upgrading package through the master, performs slice transmission, and the slave synchronously receives and verifies the upgrading package, in a 1 master 9 slave (10 energy storage cabinets) scene, the upgrading time is shortened from 50 minutes to 13 minutes, 74% time is saved, and when the number of slaves increases, the time consumption increases gently, avoiding the linear increase of time consumption in the traditional method, and reducing the on-site upgrading cost of the distributed energy storage cabinet.

[0032] (2) Upgrade security and compatibility enhancement: adopt multi-layer verification mechanism, upgrade package total CRC (CRC-32) and small package CRC (CRC-16) double check to prevent malicious firmware injection; support heterogeneous devices such as PCS, BMS of different manufacturers, adapt EMS / BMS upgrade through firmware header device type identification, solve the problem of 30% upgrade failure rate caused by protocol inconsistency and version difference in traditional scheme, and ensure the safety of power grid side.

[0033] (3) Realize online non-stop upgrade: rely on master-slave machine upgrade state cooperation mechanism, the whole system power supply is not interrupted during the upgrade process, avoid long time power supply interruption caused by traditional shutdown upgrade, ensure the operation benefit of industrial and commercial storage system, reduce manual intervention and operation error risk. BRIEF DESCRIPTION OF DRAWINGS

[0034] In order to more clearly illustrate the technical solutions of the embodiments of the present application or the prior art, the drawings needed in the embodiments will be briefly described below. The features and advantages of the present application can be more clearly understood by referring to the drawings. The drawings are schematic and should not be understood as any limitation on the present application. For those skilled in the art, other drawings can be obtained without creative labor on the basis of these drawings. Among them:

[0035] Figure 1 The flow chart of the master-slave machine parallel upgrading method of the industrial and commercial storage system provided by the present application;

[0036] Figure 2 The system communication topology of the present application;

[0037] Figure 3 The master-slave machine parallel upgrading interaction diagram of the present application;

[0038] Figure 4 The comparison diagram of experimental group and control group data results of the present application;

[0039] Figure 5 The block diagram of the master-slave machine parallel upgrading system of the industrial and commercial storage system provided by the present application. DETAILED DESCRIPTION

[0040] In order to make the purpose, technical scheme and advantages of the embodiments of the present application more clear, the technical scheme in the embodiments of the present application will be described clearly and completely below in combination with the drawings in the embodiments of the present application. Obviously, the described embodiments are part of the embodiments of the present application, not all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative labor belong to the scope of protection of the present application.

[0041] Embodiment one: in order to solve the problems of low upgrading efficiency, poor security, insufficient compatibility and power interruption caused by shutdown during the upgrading process in the prior art. As shown in Figure 1 The application provides a master-slave machine parallel upgrading method for a power storage system, which comprises the following steps:

[0042] S1: a master machine receives an OTA upgrading command issued by a cloud platform, the OTA upgrading command comprising a server address and an upgrading package total CRC check value; after receiving the OTA upgrading command, the master machine enters an upgrading state, connects to a specified server to download a firmware upgrading package, the firmware upgrading package comprising a firmware header and an upgrading package, and stores the firmware upgrading package and the upgrading package total CRC check value in a local backup storage area according to a device type identifier of the firmware header;

[0043] S2: the master machine reads the upgrading package and the upgrading package total CRC check value in the local backup storage area, calculates an upgrading package total CRC calculation value through a CRC algorithm, compares the upgrading package total CRC check value with the upgrading package total CRC calculation value, and if the two values are consistent, it is determined that the upgrading package is legal and the check is passed, and then S3 is performed, otherwise, the upgrading state is exited and the upgrading process is ended;

[0044] S3: the master machine notifies all slave machines to enter the upgrading state, synchronizes the upgrading package total size and the upgrading package total CRC check value to the slave machines, and the slave machines enter the upgrading state based on a master-slave machine upgrading state coordination mechanism and save the upgrading package total size and the upgrading package total CRC check value to a cache area;

[0045] S4: the master machine adopts a fragmentation transmission method, splits the upgrading package into multiple small packages according to a preset size, and sends the small packages to the slave machines one by one; after receiving the small packages, the slave machines calculate and check small package CRC values, and if the check is passed, the small packages are stored in the local backup storage area and do not need to be immediately fed back to the master machine; the master machine queries the receiving state of the slave machines in address order after sending a preset number of small packages, and if all the slave machines receive normally, the remaining small packages are continuously sent, otherwise, the slave machines are notified to exit the upgrading state and the upgrading process is ended;

[0046] S5: the master machine queries the upgrading package total CRC calculation value in the local backup storage area of the slave machines one by one; the slave machines calculate the local upgrading package total CRC calculation value through a CRC algorithm and feed back to the master machine; the master machine compares the upgrading package total CRC calculation values fed back by all the slave machines with the upgrading package total CRC check value, and if the two values are consistent, S6 is performed, otherwise, all the slave machines are notified to exit the upgrading state and the upgrading process is ended;

[0047] S6: the master machine notifies all the slave machines to perform upgrading, and the slave machines perform upgrading on the corresponding devices according to the device type identifier of the locally stored firmware header; after the master machine notifies all the slave machines to perform upgrading, the master machine performs upgrading on the corresponding devices according to the device type identifier of the locally stored firmware header;

[0048] S7: After the master-slave upgrade is completed, the master-slave enters an initialization state, and then enters a parallel machine process; the master queries all slave version information based on a version checking method, checks the consistency of the master-slave version, if consistent, the system enters a normal operation state, if inconsistent, the system enters a fault state.

[0049] From the above technical solution, the application provides a master-slave parallel machine upgrade method for industrial and commercial storage systems, wherein S1 realizes accurate receiving and storage of upgrade packages, S2 guarantees the legality and tamper resistance of upgrade packages, S3 ensures the coordinated and unified upgrade state of the master and slave, S4 improves the transmission efficiency and abnormal control of upgrade packages, S5 verifies the integrity of the slave upgrade package, S6 realizes targeted synchronous upgrade of the master and slave, and S7 guarantees the consistent and stable operation of the system after upgrade, thereby solving the problems of low upgrade efficiency, poor security, insufficient compatibility and the need for downtime of the traditional upgrade.

[0050] As shown in Figure 2 , the application is based on modular expansion design, and a standard industrial and commercial energy storage integrated cabinet is used as a basic hardware unit. One energy management system (EMS) module and one battery management system (BMS) module are integrated in a single cabinet. The functions and connection modes of each module are as follows:

[0051] (1) Module communication connection

[0052] Cabinet communication: The EMS module and the BMS module realize data interaction through the CAN bus, the communication baud rate is set to 250 kbps, and the real-time transmission of battery state monitoring, charge and discharge control and other data is ensured.

[0053] Parallel machine communication: When multiple cabinet bodies are connected in parallel, the EMS modules of each cabinet body are connected through the 485 bus, and the baud rate is configured as 115200 bps, to ensure stable transmission of upgrade instructions and upgrade package data between the master and slave.

[0054] (2) Master-slave distribution rule

[0055] Master selection: In the parallel machine system, an EMS module of a cabinet body is randomly selected as the master, and its address is fixed as 1, which undertakes the core responsibilities of upgrade package receiving, distribution, state coordination and version checking.

[0056] Slave configuration: The EMS modules of the remaining cabinet bodies are all slave machines, and the addresses start from 2 and increase sequentially, supporting up to 9 slave machines (i.e. 10 cabinet bodies connected in parallel), meeting the expansion needs of small and medium-sized industrial and commercial energy storage scenarios.

[0057] Cloud platform access: The master EMS module is connected with the cloud platform through Ethernet or 4G network, realizing remote interaction functions such as OTA upgrade command receiving and upgrade state reporting, without the need for on-site manual intervention.

[0058] The upgrade process of this invention follows the logic of preparation-verification-distribution-upgrade-verification, consisting of 7 core steps. Combined with an exception handling mechanism, it ensures efficient, secure, and reliable upgrades. Figure 3 As shown, the specific process is as follows:

[0059] In step S1, the host obtains and stores the firmware upgrade package:

[0060] S11: The cloud platform sends an OTA upgrade command to the host via Ethernet / 4G network. The command includes the server address where the upgrade package is located and the total CRC check value of the upgrade package (generated using the CRC-32 algorithm).

[0061] S12: After receiving the command, the host automatically exits the normal operation state and enters the "upgrade state". It establishes a network connection based on the server address and downloads the firmware upgrade package (the package body contains the firmware header and the upgrade package body. The firmware header contains the version number, device type identifier (EMS / BMS), and system model).

[0062] S13: The host stores the firmware upgrade package and the total CRC check value of the upgrade package into the corresponding local backup storage area (EMS and BMS partitioned storage to avoid confusion) according to the device type identifier in the firmware header. After storage is completed, proceed to the next step.

[0063] In step S2, the host verifies the validity of the local upgrade package:

[0064] S21: The host reads the upgrade package body and the total CRC check value of the upgrade package from the local backup storage area, and calculates the total CRC value of the upgrade package using the CRC-32 algorithm.

[0065] S22: Compare the total CRC checksum value with the total CRC calculated value of the upgrade package:

[0066] If both are consistent: the upgrade package is deemed legal and complete, proceed to step S3;

[0067] If there is a discrepancy: if the upgrade package is deemed damaged or tampered with, the host will immediately exit the upgrade state, end the upgrade, and report an upgrade package verification failure to the cloud platform.

[0068] In step S3, the host notifies the slave of the synchronization upgrade status.

[0069] S31: The host sends an upgrade state command to all slaves via the 485 bus, and synchronously transmits two key parameters: the total size of the upgrade package and the total CRC check value of the upgrade package.

[0070] S32: After receiving the instruction, the slave device exits the normal operation state and enters the upgrade state based on the master-slave upgrade state coordination mechanism. It stores the total size of the upgrade package and the total CRC check value in the local cache for subsequent verification. After completing the state synchronization, it waits for the next instruction from the master.

[0071] In step S4, the host transmits the upgrade packet in fragments and verifies the slave's reception status.

[0072] S41: The host uses a fragmented transmission method to split the upgrade package into multiple small packets of a preset size of 256-1024 bytes. Each small packet is accompanied by a CRC check value generated based on the CRC-16 algorithm and is sent to the slave device one by one through the 485 bus.

[0073] S42: After receiving the small packet, the slave device first verifies the integrity of the small packet using the CRC checksum of the small packet:

[0074] Verification successful: Store the small packet in the local backup storage area without immediate response to the host;

[0075] Verification failed: The error record is temporarily stored and awaits query from the host.

[0076] S43: After the host sends a preset number of small packets (e.g., 10), it sends a receive status query command in the order of the slave device addresses (incrementing from 2):

[0077] After receiving the query command, the slave device will provide feedback on the status information such as the number of small packets received and the number of erroneous small packets.

[0078] The master summarizes the status of all slave devices:

[0079] If all slave devices receive the packets normally (no erroneous packets): continue to send the remaining packets;

[0080] If there is a slave receiving anomaly (with erroneous small packets): the master records the erroneous fragment number, starts the breakpoint resume protocol, and only resends the erroneous fragment; if the same fragment fails to be verified 3 times in a row, the upgrade transmission is determined to be abnormal, the master notifies all slaves to exit the upgrade state, ends this upgrade, and reports to the cloud platform.

[0081] In step S5, the host verifies the integrity of the local upgrade package on the slave device.

[0082] S51: The host queries the total CRC value of the upgrade package in the local backup storage area of ​​the slave device one by one through the 485 bus, and sends the total CRC query command of the upgrade package to the slave device.

[0083] S52: After receiving the instruction, the slave device calculates the total CRC value of the local storage upgrade package using the CRC-32 algorithm and sends it back to the host.

[0084] S53: The host summarizes the total CRC calculation value of all slave devices and compares it one by one with the total CRC checksum value of the upgrade package in step 1:

[0085] If the calculated values ​​of all slave devices are consistent with the verification value: the slave device upgrade package is determined to be complete, and proceed to step 6;

[0086] If there is a discrepancy in the calculated values ​​of the slave devices: the slave device upgrade package is determined to be corrupted, the master device notifies all slave devices to exit the upgrade state, ends the upgrade, and reports to the cloud platform.

[0087] In step S6, the master and slave machines synchronously perform the upgrade operation.

[0088] S61: The master sends an "execute upgrade" command to all slaves via the 485 bus.

[0089] S62: After receiving the instruction, the slave device reads the device type identifier (EMS / BMS) in the firmware header of the local backup storage area and performs the upgrade operation on the corresponding device (if the identifier is EMS, the EMS module is upgraded; if the identifier is BMS, the BMS module is upgraded).

[0090] S63: After the host sends the upgrade command, it synchronously reads the device type identifier in its own firmware header and performs the upgrade operation on the corresponding device to ensure that the upgrade actions of the master and slave are synchronized and to avoid version differences.

[0091] In step S7, the master / slave version is verified and the state is switched.

[0092] S71: After the master-slave upgrade is completed, it automatically enters the initialization state, completes the device self-test (such as module communication test and function initialization), and then enters the parallel operation process.

[0093] S72: Master boot version verification method: Poll all slave devices through the MODBUS RTU protocol to obtain the slave device ID, system model and version number.

[0094] S73: The host compares the slave's system model and version number with its own system model and version number one by one:

[0095] If all slave devices have the same system model and version number as the master device: the version verification is passed, the system as a whole enters normal operation and the energy storage service is restored;

[0096] If there is a mismatch in the slave system model or version number: the upgrade is determined to be abnormal, the system enters a fault state, the host reports the version inconsistency abnormality to the cloud platform and triggers a local alarm (such as indicator light flashing), and waits for manual intervention.

[0097] Furthermore, to address abnormal scenarios such as communication interruptions and device offline during the upgrade process, this invention designs three core exception handling mechanisms to ensure system security and stability:

[0098] Master heartbeat detection mechanism: During the upgrade process, the master sends a "heartbeat detection" command to all slave devices every 30 seconds (configurable) to check the online status of the slave devices.

[0099] If the slave device responds within 10 seconds: the slave device is determined to be online, and the upgrade process continues;

[0100] If the slave device does not respond for more than 10 seconds: it is determined that the slave device is offline. The host immediately notifies all slave devices to exit the upgrade state, ends the upgrade, and reports the slave device offline anomaly to the cloud platform.

[0101] Slave Receive Timeout Mechanism: After the slave device enters the upgrade state, if it does not receive any instructions (including upgrade package delivery, status query, etc.) from the host within 60 seconds (configurable), it will automatically determine that the host communication is interrupted, actively exit the upgrade state, and restore the normal operating state before the upgrade, so as to avoid the impact of being in the upgrade state for a long time on the business.

[0102] Fragmentation transmission retry mechanism: In step S4, if the slave device reports a small packet verification failure, the master device starts the breakpoint resume transmission and only resends the erroneous fragment; if the same fragment fails verification 3 times in a row, the transmission link is determined to be abnormal, and the upgrade is terminated immediately to avoid wasting time and resources on invalid retries.

[0103] To verify the upgrade efficiency advantage of this invention, an experimental system was built, consisting of one master unit and nine slave units (a total of ten energy storage cabinets). The upgrade time of the method of this invention (experimental group) was compared with that of the traditional step-by-step upgrade method (control group). The experimental data and results are as follows:

[0104] I. Experimental Setup

[0105] 1. Experimental equipment: 10 integrated industrial and commercial energy storage cabinets (each containing 1 EMS and 1 BMS). The host is connected to the cloud platform via Ethernet, and the master and slave units communicate via a 485 bus.

[0106] 2. Upgrade packages: EMS firmware upgrade package (5MB), BMS firmware upgrade package (2MB).

[0107] 3. Control group operation: Manually connect to each slave device one by one, transmit the upgrade package through the local interface and execute the upgrade, and manually verify the version after the upgrade is completed.

[0108] 4. Experimental group operation: Based on the method of this invention, OTA commands are issued through the cloud platform to automatically execute the upgrade process.

[0109] II. Experimental Data

[0110] Comparison of data results between the experimental group and the control group, such as Figure 4 As shown, the horizontal axis represents the number of slave devices, and the vertical axis represents time (minutes).

[0111] III. Experimental Conclusions

[0112] The data results show that the experimental group, using the method of this invention, significantly shortened the upgrade time. As the number of slave units increases, the upgrade time required by traditional methods rises sharply, while the time required by the experimental group remains relatively constant and does not increase dramatically with the number of slave units, demonstrating the advantage of this invention in upgrade efficiency. Specifically, in a system containing 10 energy storage cabinets (1 master unit and 9 slave units), the experimental group saved 74% of the upgrade time compared to the control group (13 minutes for the experimental group and 50 minutes for the control group). This result verifies the efficiency and practicality of this invention in master-slave parallel upgrades of industrial and commercial energy storage systems.

[0113] Example 2: Figure 5 As shown, this invention provides a master-slave parallel upgrade system for an industrial and commercial storage system. This system is used to implement the master-slave parallel upgrade method for an industrial and commercial storage system according to Embodiment 1 above, specifically including:

[0114] The host module 100 is used to receive OTA upgrade commands issued by the cloud platform, connect to the specified server to download the firmware upgrade package and store it according to the device type identifier in the firmware header, verify the legality of the upgrade package, coordinate all slaves to enter the upgrade state based on the master-slave upgrade status coordination mechanism, perform fragmented transmission and slave status query, trigger master-slave upgrade operation, and verify the consistency of master-slave version.

[0115] The slave module 200 is used to receive upgrade status notifications and upgrade packets from the master module, verify and store the CRC value of the packets, provide feedback on the reception status and the total CRC calculation value of the upgrade packets, execute the corresponding device upgrade according to the master module's instructions, and participate in version verification in the parallel operation process.

[0116] The communication module 300 is used to realize data transmission between the master module and the slave module;

[0117] The upgrade management module 400 is used to manage the generation, distribution, verification, and command issuance of upgrade packages.

[0118] Specifically, the industrial and commercial storage system master-slave parallel upgrade system consists of a master module 100, a slave module 200, a communication module 300, and an upgrade management module 400. These modules work collaboratively to cover the functional requirements of the entire upgrade process. Their specific architecture and responsibilities are as follows:

[0119] Main Unit Module 100: The core control unit for system upgrades, possessing four core functions:

[0120] Upgrade package processing: Receive OTA upgrade commands (including server address and total CRC checksum of upgrade package) issued by the cloud platform, connect to the specified server to download firmware upgrade package (including firmware header and upgrade package body), and store the upgrade package and checksum in the local backup storage area according to the device type identifier (EMS / BMS) in the firmware header to avoid conflict with running firmware.

[0121] Legality verification: The total CRC value of the locally stored upgrade package is calculated using the CRC-32 algorithm and compared with the total CRC checksum of the upgrade package in the OTA command to verify the integrity and legality of the upgrade package and prevent malicious firmware injection.

[0122] State coordination: Based on the master-slave upgrade state coordination mechanism, all slaves are notified to enter the upgrade state, and key information such as the total size of the upgrade packet and the total CRC check value are synchronized. The slaves' reception status and upgrade packet verification results are queried in address order to ensure that the master and slave states are consistent.

[0123] Version verification: After the upgrade is completed, all slave devices are polled through the MODBUS RTU protocol to obtain the device ID, system model and version number of the slave devices, and compared with its own information to confirm the consistency of the master and slave versions and determine whether the system has entered normal operation.

[0124] Slave module 200: An execution unit that receives master commands and performs upgrade operations, with functions including:

[0125] Command Response: Receive upgrade status notifications and upgrade package data from the host, and enter / exit the upgrade state based on preset logic to avoid system oscillations caused by independent operations.

[0126] Local verification and storage: After receiving the upgrade package, the integrity of the package is verified by the CRC-16 algorithm. If the verification is successful, the package is stored in the local backup storage area without immediate reply to the host, thus reducing communication redundancy. After the upgrade package is received, the total CRC value of the local upgrade package is calculated and fed back to the host.

[0127] Upgrade execution: Based on the upgrade command issued by the host and combined with the device type identifier in the firmware header stored locally, perform the upgrade operation on its own EMS or BMS module, and participate in the parallel operation process and version verification after the upgrade.

[0128] Communication Module 300: A link unit that ensures data transmission between the master / slave machine, the host machine, and the cloud platform, designed using a layered communication protocol.

[0129] Master-slave communication: Based on the 485 bus and MODBUS RTU protocol, it realizes the transmission of data such as upgrade commands, upgrade packet fragmentation, and status feedback, with a baud rate of 115200bps to ensure transmission efficiency and stability.

[0130] Host-cloud platform communication: Receives OTA upgrade commands and reports upgrade progress via Ethernet or 4G network based on TCP / IP protocol, and supports remote monitoring and anomaly intervention.

[0131] Upgrade Management Module 400: Upgrade the entire process control unit, deployed on the cloud platform, with the following functions:

[0132] Upgrade package management: Generate firmware upgrade packages adapted to different device types (EMS / BMS) and different system models, with firmware headers (including version number, device type identifier, system model) and CRC-32 total checksum.

[0133] Command issuance: Sends an OTA upgrade command to the host, including key parameters such as the server address and the total CRC checksum of the upgrade package, to trigger the upgrade process.

[0134] Anomaly monitoring: Receives upgrade status reports from the host in real time (such as slave offline, fragmentation transmission failure), supports remote termination of abnormal upgrade processes, and reduces system risks.

[0135] This embodiment provides a master-slave parallel upgrade system for an industrial and commercial storage system, used to implement the aforementioned master-slave parallel upgrade method for an industrial and commercial storage system. Therefore, the specific implementation of the master-slave parallel upgrade system for an industrial and commercial storage system can be found in the embodiment section of the aforementioned master-slave parallel upgrade method for an industrial and commercial storage system. For example, the master module 100, slave module 200, communication module 300, and upgrade management module 400 are respectively used to implement steps S1, S2, S3, and S4 in the aforementioned master-slave parallel upgrade method for an industrial and commercial storage system. Therefore, the specific implementation can be referred to the description of the corresponding embodiments. To avoid redundancy, it will not be repeated here.

[0136] Example 3: This embodiment of the invention provides an electronic device, which includes a processor, a memory, and a bus system. The processor and the memory are connected through the bus system. The memory is used to store instructions, and the processor is used to execute the instructions stored in the memory, so as to realize the above-mentioned master-slave parallel upgrade method for an industrial and commercial storage system.

[0137] Example 4: This embodiment of the invention provides a computer storage medium storing computer software products. The computer software products include several instructions to cause a computer device to execute the above-described master-slave parallel upgrade method for an industrial and commercial storage system.

[0138] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0139] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0140] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The functions specified in one or more boxes. These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable apparatus for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0141] Obviously, the above embodiments are merely illustrative examples for clear explanation and are not intended to limit the implementation. Those skilled in the art will recognize that other variations or modifications can be made based on the above description. It is neither necessary nor possible to exhaustively list all possible implementations here. However, obvious variations or modifications derived therefrom are still within the scope of protection of this invention.

Claims

1. A method for upgrading a master-slave computer system, characterized in that, The method comprises the following steps: S1: the host receives an OTA upgrade command issued by a cloud platform, wherein the OTA upgrade command comprises a server address and a total CRC check value of an upgrade package; After receiving the OTA upgrade command, the host enters an upgrade state, connects to a specified server to download a firmware upgrade package, the firmware upgrade package comprises a firmware header and an upgrade package, and the firmware upgrade package and the total CRC check value of the upgrade package are stored in a local backup storage area according to a device type identifier of the firmware header; The total CRC check value of the upgrade package is generated by using a CRC-32 algorithm, the firmware header comprises a version number, a device type identifier and a system model, and the host preliminarily screens an adaptive upgrade package storage path by using the system model of the firmware header; S2: the host reads the total CRC check value of the upgrade package and the total CRC check value of the upgrade package in the local backup storage area, calculates a total CRC calculation value of the upgrade package by using a CRC algorithm, compares whether the total CRC check value of the upgrade package and the total CRC calculation value of the upgrade package are consistent, if yes, it is determined that the upgrade package is legal and the check is passed, and S3 is performed, otherwise, the upgrade state is exited and the current upgrade is ended; S3: the host notifies all slaves to enter an upgrade state, synchronizes the total size of the upgrade package and the total CRC check value of the upgrade package to the slaves, the slaves enter the upgrade state based on a master-slave upgrade state coordination mechanism, and the total size of the upgrade package and the total CRC check value of the upgrade package are saved to a cache area; S4: the host uses a fragmentation transmission method to split the upgrade package into a plurality of small packages according to a preset size, and sequentially issues the small packages to the slaves; after receiving the small packages, the slaves calculate and check small package CRC values, and if the check is passed, the small packages are stored in the local backup storage area without immediate feedback to the host; after issuing a preset number of small packages, the host queries the receiving state of the slaves in address order, if all the slaves receive normally, the remaining small packages are continuously issued, otherwise, the slaves are notified to exit the upgrade state and the current upgrade is ended; The size of the small package is 256 bytes to 1024 bytes, each small package is attached with a small package CRC check value generated based on a CRC-16 algorithm, and the slave first verifies the integrity of the small package by using the small package CRC check value and then performs a storage operation; When the fragmentation transmission check fails, the host records the number of the current error fragment, starts a breakpoint resume transmission protocol, and only reissues the error fragment; if the same fragment fails for three times in succession, it is determined that the upgrade transmission is abnormal, the host notifies all the slaves to exit the upgrade state and ends the current upgrade; S5: the host sequentially queries the total CRC calculation value of the upgrade package in the local backup storage area of the slave; the slave calculates the total CRC calculation value of the local upgrade package by using a CRC algorithm and feeds back to the host; the host compares the total CRC calculation value of the upgrade package fed back by all the slaves with the total CRC check value of the upgrade package, if they are consistent, S6 is performed, otherwise, all the slaves are notified to exit the upgrade state and the current upgrade is ended; S6: the host notifies all the slaves to perform the upgrade, the slave performs the upgrade on the corresponding device according to the device type identifier of the locally stored firmware header, and the host performs the upgrade on the corresponding device according to the device type identifier of the locally stored firmware header. S7: After the master-slave upgrade is completed, the master-slave enters an initialization state, and then enters a parallel machine process; the master queries version information of all slaves based on a version checking method, checks consistency of versions of the master and the slaves, if the versions are consistent, the system enters a normal operation state, if the versions are inconsistent, the system enters a fault state; The version checking method is specifically: the master polls all slaves through a MODBUS RTU protocol, obtains device IDs, system models and version numbers of the slaves, compares the system models and the version numbers of the slaves with system model and version number of the master, if the system models of all slaves match the master and the version numbers are consistent, it is determined that the version checking is passed; The method further comprises: the master detects an online state of the slave in a regular time, if the slave does not respond within the regular time, it is determined that the slave is offline, the master notifies all slaves to exit this upgrade, and ends this upgrade; The method further comprises: the slave actively exits the upgrade state when the slave does not receive a master instruction within a predetermined time.

2. A master-slave computer parallel upgrading system for a business storage system, characterized in that, The system is used to implement the parallel machine upgrade method of the industrial and commercial storage system master-slave as claimed in claim 1, and specifically comprises: A master module is used to receive an OTA upgrade command issued by a cloud platform, connect a specified server to download a firmware upgrade package and store the firmware upgrade package according to a firmware header device type identifier, check legality of the upgrade package, coordinate all slaves to enter an upgrade state based on a master-slave upgrade state coordination mechanism, perform slice transmission and slave state query, trigger master-slave upgrade operations, and check consistency of versions of the master and the slaves; A slave module is used to receive an upgrade state notification and an upgrade package packet of the master module, check and store a CRC value of the packet, feed back a receiving state and a total CRC calculation value of the upgrade package, perform corresponding device upgrade according to an instruction of the master module, and participate in version checking in the parallel machine process; A communication module is used to implement data transmission between the master module and the slave module; An upgrade management module is used to manage generation, distribution, checking and command issuing of the upgrade package.

3. An electronic device, comprising: The electronic device comprises a processor, a memory and a bus system, the processor and the memory are connected through the bus system, the memory is used to store instructions, and the processor is used to execute the instructions stored in the memory to implement the parallel machine upgrade method of the industrial and commercial storage system master-slave as claimed in claim 1.

4. A computer storage medium, characterized in that, The computer storage medium stores a computer software product, the computer software product comprises instructions for executing the parallel machine upgrade method of the industrial and commercial storage system master-slave as claimed in claim 1.

Images