Packed battery management system and remote upgrading method thereof

Abstract

The invention relates to the technical field of battery management, and discloses a parallel battery management system and a remote upgrading method thereof. The master control unit sequentially sends addressing signals to the slave modules through the bidirectional signal link, receives response signals from the slave modules through the bidirectional signal link, allocates identification addresses to the slave modules, and sends the allocated identification addresses to the corresponding slave modules through the data communication link. Each slave module receives the addressing signal through the bidirectional signal link, feeds back a response signal to the main control unit through the bidirectional signal link after receiving the addressing signal, and prevents the addressing signal from being continuously transmitted to the subordinate slave module during the period of generating the response signal; after the slave module receives the identification address sent by the main control unit through the data communication link, the addressing signal is allowed to continue to be transmitted to the subordinate slave module, and the main control unit uses the identification address to perform data communication with the slave module through the data communication link; the problems that existing addressing depends on manual operation, errors are prone to occurring, and remote upgrading efficiency is low can be solved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of battery management, in particular to a parallel battery management system and a remote upgrading method thereof. BACKGROUND

[0002] With the large-scale application of new energy technology, the demand for battery capacity of mobile energy storage and household energy storage systems is increasing. By adopting the parallel battery module packaging method, the system energy storage capacity can be flexibly expanded, the initial investment cost can be reduced, and the reliability and maintainability of the system can be improved. In the parallel battery system, in order to distinguish and manage each battery module, the module needs to be addressed.

[0003] Currently, there are mainly two technical solutions for battery module addressing: The first solution is a physical addressing method. A DIP switch is provided on the BMS board of the battery module, and the battery module is addressed by different combinations of the DIP switch. After being uniformly managed by the battery management system, the energy is exchanged with the photovoltaic power generation system, the power grid and / or the load through the PCS energy storage bidirectional converter. The advantage of this method is that the hardware design is simple, the cost is low, no complex software protocol or additional electronic components are needed, the address information is determined by the physical state, and the anti-electromagnetic interference ability is strong. However, this method highly depends on manual operation, and in large-scale batch production, it is easy to cause address confusion and address omission, leading to communication disorder of the entire battery management system, which seriously reduces the production efficiency and system reliability. In addition, the address is strongly bound to the physical switch position, and the module lacks flexibility. If a single module needs to be replaced in the later maintenance, the address of the new module must be accurately set to the original address of the faulty module, which is tedious and prone to errors. As a mechanical component, the DIP switch also has the risk of contact oxidation, wear and poor contact in a vibrating environment, and its long-term reliability is not as good as that of an all-electronic addressing solution.

[0004] The second solution is a single signal line daisy chain addressing mode, which is also uniformly managed by the battery management system and interacts with the photovoltaic power generation system, power grid and / or load through the PCS energy storage bidirectional converter. In this mode, the modules are connected in series, and the main controller sends a start pulse, and each module automatically assigns a unique address in the connection order. In existing battery management system communication solutions, the CAN communication protocol in extended format is used, and the device ID is defined in the arbitration section of the data frame to realize device identification and data transmission through a multi-layer communication architecture. This solution only needs one shared communication signal line to connect all modules in series, greatly simplifying the system wiring and connector complexity, significantly reducing the cost, weight and failure rate of the wire harness. The automatic addressing mechanism upon power-up does not require any manual pre-setting or software configuration, perfectly avoiding the risk of address conflict and achieving plug-and-play intelligent production and maintenance. However, the most significant disadvantage of this approach is the "single point failure" dependency of the entire communication link. If the communication interface of any module on the link fails, it will disrupt the signal transmission of the entire link, causing all modules after it to lose connection with the main controller, and the system reliability is highly dependent on the integrity of each node, requiring step-by-step detection for maintenance and troubleshooting. Secondly, its address allocation strictly depends on the physical connection order, which means that the assembly order of the modules on the production line must be completely consistent with the logical address order of the system. If the position is assembled incorrectly, it will cause address confusion, bringing additional constraints to the production process planning and later module replacement.

[0005] In addition, there are also battery management solutions that use wireless communication to simplify the wiring structure within the battery pack. However, wireless communication methods have problems such as signal interference and insufficient communication reliability in large-scale battery systems, and have not effectively solved the problems of determinism and reliability in the automatic addressing process.

[0006] In summary, existing parallel battery system addressing solutions rely heavily on the order of physical connections or the accuracy of manual settings. This not only makes it easy to cause address conflicts and communication failures due to incorrect order or incorrect placement in large-scale production, but also greatly limits the flexibility and maintainability of the system, making it impossible to achieve plug-and-play and intelligent management of modules, and becoming a reliability bottleneck for the entire system link. At the same time, during system operation and maintenance, firmware upgrades often need to be performed on each module, which is inefficient and prone to errors, and there is a lack of efficient and reliable cluster remote upgrade solutions.

[0007] Therefore, there is an urgent need for advanced parallel battery systems to overcome the above deficiencies. SUMMARY

[0008] The present application aims to provide a parallel battery management system and a remote upgrading method thereof, so as to solve the technical problems of the prior art, such as the error-prone manual operation, the risk of single point failure, the poor system flexibility, and the lack of efficient remote upgrading mechanism.

[0009] To achieve the above object, the present application adopts the following technical solutions: In a first aspect, the present application provides a parallel battery management system, which comprises a master control unit, a bidirectional signal link, a data communication link, and a plurality of slave modules, the master control unit being a master controller of the battery management system, each of the slave modules comprising a battery unit and a slave controller connected to the battery unit, the bidirectional signal link being used for bidirectional signal transmission between the master control unit and the plurality of slave modules, and the data communication link connecting the master control unit and the plurality of slave modules. The master control unit sends an addressing signal to the plurality of slave modules in sequence through the bidirectional signal link, and receives a response signal from the slave modules through the bidirectional signal link, assigns an identification address to a corresponding slave module based on the received response signal, and sends the assigned identification address to the corresponding slave module through the data communication link. Each of the slave modules receives the addressing signal through the bidirectional signal link, feeds back a response signal to the master control unit through the bidirectional signal link after receiving the addressing signal, prevents the addressing signal from being transmitted to a lower-level slave module during the generation of the response signal, allows the addressing signal to be transmitted to a lower-level slave module after the slave module receives an identification address sent by the master control unit through the data communication link, and uses the identification address for data communication with the slave module through the data communication link.

[0010] Preferably, the bidirectional signal link comprises a forward signal line and a reverse signal line, the forward signal line being used for sequentially connecting the master control unit and the plurality of slave modules to transmit the addressing signal, and the reverse signal line being used for sequentially connecting the plurality of slave modules and the master control unit to transmit the response signal.

[0011] Specifically, each of the slave modules generates the response signal by changing an electrical state of the reverse signal line, and the change of the electrical state includes pulling the reverse signal line to a low level or pulling the reverse signal line to a high level.

[0012] Further, each of the slave modules comprises a first signal interface for connecting to a superior node, a second signal interface for connecting to an inferior node, a response control circuit and a signal transfer switch, the first signal interface comprises an input end for receiving an addressing signal and an output end for outputting a response signal, the second signal interface comprises an output end for sending an addressing signal to an inferior node, the response control circuit is used for generating and sending the response signal after receiving the addressing signal; The signal transfer switch is arranged between the signal output end of the slave module and the second signal interface, and is used for being disconnected to prevent the addressing signal from being transferred to the inferior node during generation of the response signal, and being connected to allow the addressing signal to be transferred to the inferior node after the slave module receives the identification address. The head end of the bidirectional signal link is connected to the master control unit, and the tail end is terminated through a matching resistance.

[0013] Further, the forward signal line and the reverse signal line respectively comprise a differential signal pair, the bidirectional signal link is a differential signal chain network, and the data communication link is a local area network bus.

[0014] Specifically, the plurality of slave modules are connected in series, and the head node and the tail node are connected through the redundant bidirectional signal link to form a ring topology with a redundant path, the addressing signal is transferred between the plurality of slave modules in a first direction, and the response signal is transferred in a second direction opposite to the first direction, and when a path fails, the master control unit continues the addressing process through another path.

[0015] Preferably, the master control unit comprises a signal chain control module, a data communication control module and an address allocation module, the signal chain control module is used for managing sending of the addressing signal and receiving of the response signal of the bidirectional signal link; The data communication control module is used for managing data transmission of the data communication link; The address allocation module is used for allocating a continuously increasing identification address to a corresponding slave module according to a time sequence order of receiving the response signal, and synchronizing an address mapping relationship to the data communication control module.

[0016] Preferably, the master control unit further monitors a receiving state of the response signal, and when the master control unit does not receive the response signal within a preset timeout time, it is determined that there is a faulty node at the current position, and the number of slave modules that have successfully received the response signal is recorded as the position of the faulty node in the addressing sequence and the addressing process is terminated.

[0017] Preferably, the response signal generated by each of the slave modules carries a hardware unique identifier of the slave module, and the master control unit can extract the hardware unique identifier and establish a mapping relationship between the identification address and the hardware unique identifier to verify the correctness of the addressing.

[0018] In a second aspect, the present application provides a remote upgrading method for a parallel battery management system, the system comprising a master control unit, a communication network and a plurality of slave modules, each of the slave modules storing a current version identifier, the remote upgrading method comprising the following steps: S1, the master control unit acquires an upgrading firmware file from a remote server via a wireless communication module and stores the file; S2, the master control unit broadcasts an upgrading notification message via the communication network, the message containing a target version identifier; S3, upon receiving the upgrading notification message, each of the slave modules compares the target version identifier with its corresponding current version identifier, and when the target version identifier is higher than the current version identifier, the slave module determines that an upgrade is needed and sends an upgrading request to the master control unit, and when the target version identifier is lower than or equal to the current version identifier, the slave module remains silent; S4, upon receiving the upgrading request, the master control unit divides the upgrading firmware file into a plurality of data blocks and sends them to the slave module requesting the upgrade in sequence, each of the data blocks containing a block sequence number and a check value; S5, upon receiving each data block, each of the slave modules checks the integrity of the data block according to the check value, and sends a confirmation message containing the block sequence number to the master control unit after the check is passed; S6, upon receiving all data blocks, each of the slave modules calculates an overall check value and compares it with a pre-stored standard check value, and performs a firmware updating operation after the overall check is passed.

[0019] Preferably, the check value is a cyclic redundancy check code, the overall check value is a hash value generated by a message digest algorithm, and the process of comparing the target version identifier with the current version identifier by each of the slave modules comprises: extracting the major version number, the minor version number and the revision number in the target version identifier; preferentially comparing the major version numbers, further comparing the minor version numbers when the major version numbers are the same, and further comparing the revision numbers when both the major version numbers and the minor version numbers are the same.

[0020] Preferably, the master control unit re-sends the data block when it does not receive a confirmation message within a preset timeout period, and marks the corresponding slave module as an upgrade failure and continues to send data blocks to other slave modules when the number of retransmissions exceeds a preset threshold; Each of the slave modules backs up the current firmware to a backup storage area before performing the firmware updating operation, and verifies the function of the new firmware by executing a self-checking program after the firmware is updated, and recovers the current firmware from the backup storage area and reports an upgrade failure to the master control unit when the self-checking fails.

[0021] Preferably, the master unit requests all slave modules to report the current version identifier through the communication network after the firmware update operation is completed, and compares all received version identifiers with the target version identifier; When the version identifiers of all slave modules are consistent with the target version identifier, it is determined that the upgrade is successful this time; When there is a slave module with an inconsistent version identifier, record the upgrade failure and trigger an abnormal processing procedure.

[0022] Compared with the prior art, the present application has the following beneficial effects: On the one hand, the present application realizes full-automatic, conflict-free intelligent addressing by realizing forward transmission of addressing signals and reverse feedback of response signals through a bidirectional signal link, ensuring the sequence and certainty of the addressing process through a bidirectional handshake mechanism, fundamentally eliminating address errors and conflicts caused by manual dialing or software competition, and greatly improving production efficiency and system reliability; on the other hand, the present application uses a double-layer network architecture to physically isolate the bottom addressing signal chain from the upper data communication link, make the function special, and through redundant path design, any node or cable failure will not cause system paralysis, and the signal can be transmitted through another path, significantly improving the fault tolerance and availability of the system; on the other hand, the intelligent upgrade decision mechanism based on version number enables each slave module to independently determine whether it needs to be upgraded, and through the data transmission process of block checking and confirmation, the atomicity, consistency and transmission reliability of firmware update in a large-scale battery system are ensured, realizing efficient and reliable cluster remote upgrade, effectively avoiding system compatibility chaos caused by single-point upgrade failure, and significantly improving the intelligent level and operation stability of the battery system in the whole life cycle of production deployment, later maintenance and remote upgrade.

[0023] The present application has other characteristics and advantages, which will be apparent or will be described in detail in the accompanying drawings and subsequent detailed description incorporated herein, which together serve to explain the specific principles of the present application. BRIEF DESCRIPTION OF DRAWINGS

[0024] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the prior art, the accompanying drawings needed to be used in the embodiments or prior art description will be briefly introduced as follows. Obviously, the accompanying drawings in the following description are only some embodiments of the present application, and for those skilled in the art, other drawings can also be obtained without creative labor on the basis of these drawings.

[0025] Figure 1 A physical addressing system block diagram of the prior art battery module; Figure 2 A parallel battery system block diagram for prior art two single signal line daisy chain addressing; Figure 3 A parallel battery system block diagram for bidirectional parallel machine signal and CAN communication module of embodiment one of the application; Figure 4 A flowchart block diagram of the remote upgrade method of the parallel battery management system of embodiment two of the application. DETAILED DESCRIPTION

[0026] To explain the possible application scenarios, technical principles, specific implementation schemes, and the purposes and effects that can be achieved of the present application in detail, the following specific embodiments are combined with the accompanying drawings. The embodiments described herein are only used to more clearly illustrate the technical solutions of the present application, and therefore only serve as examples, but cannot limit the protection scope of the present application. Embodiment one

[0027] Please refer to Figure 3 The parallel battery management system 100 of the present embodiment can be applied to mobile energy storage, household energy storage, industrial energy storage and other application scenarios that require multiple battery modules in parallel expansion. Through the double-layer network architecture of the bidirectional signal link and the data communication link 30, the system realizes full-automatic addressing and intelligent management of the battery modules. Specifically, the core technical idea of the present embodiment is: an independent bidirectional signal link is used to specialize in the addressing process, and the bidirectional handshake mechanism is used to ensure the certainty and reliability of the addressing; at the same time, the data communication link 30 is used for normal data transmission, the addressing function and the data communication function are physically isolated to avoid mutual interference. Figure 3 The overall architecture block diagram of the parallel battery management system 100 of the present embodiment is shown.

[0028] The parallel battery management system 100 of the present embodiment includes a master control unit 10, a bidirectional signal link, a data communication link 30 and multiple slave modules 40. The master control unit 10 can be subsequently electrically connected to a PCS energy storage bidirectional converter 300 for energy conversion and / or external power supply through the energy storage bidirectional converter 300. To better illustrate the technical solution, the present embodiment takes a parallel battery energy storage system containing 3 battery modules as a specific application scenario for detailed description. In this application scenario, the system includes 1 master control unit 10 and 3 slave modules 40, wherein each slave module 40 is equipped with a battery unit 41 and a slave controller 42.

[0029] The master control unit 10 is the master controller of the battery management system, responsible for monitoring, managing and data processing of the entire parallel system. In the present embodiment, the master control unit 10 integrates a microprocessor, a wireless communication module, a CAN bus interface and a bidirectional signal link interface.

[0030] Each slave module 40 includes a battery unit 41 and a slave controller 42 connected with the battery unit 41. Specifically, the battery unit 41 can be a single battery cell or a combination of multiple battery cells. The slave controller 42 is responsible for voltage, current, temperature monitoring of the battery unit 41 and communication with the master controller 10. In the present embodiment, each slave controller 42 is integrated with an AFE chip for battery parameter acquisition, and a microcontroller for data processing and communication.

[0031] The data communication link 30 connects the master controller 10 with the plurality of slave modules 40, and is used for normal data transmission. In the present embodiment, the data communication link 30 is a local area network bus, specifically a CAN bus.

[0032] It should be noted that the data communication link 30 herein is preferably a CAN bus, and of course other types of multi-master communication lines can also be used according to actual needs. When the data communication link 30 is of other types of multi-master communication lines, the CAN bus interface needs to be replaced with other types of multi-master communication line interfaces.

[0033] The bidirectional signal link is used for bidirectional signal transmission between the master controller 10 and the plurality of slave modules 40, and is different from the data communication link 30 used for normal data transmission. The bidirectional signal link of the present embodiment is specifically used for addressing procedures.

[0034] In the present embodiment, the bidirectional signal link includes a forward signal line 21 and a reverse signal line 22, wherein the forward signal line 21 is used to connect the master controller 10 with the plurality of slave modules 40 in sequence (i.e. the master controller 10 and the plurality of slave modules 40 are connected in series through the forward signal line 21 to form an addressing path) to transmit addressing signals, and the reverse signal line 22 is used to connect the plurality of slave modules 40 with the master controller 10 in sequence (i.e. the master controller 10 and the plurality of slave modules 40 are connected in series through the reverse signal line 22 to form a response path) to transmit response signals.

[0035] Preferably, the forward signal line 21 and the reverse signal line 22 each include a differential signal pair, that is, the bidirectional signal link of the present embodiment is a differential signal link network, which can use differential signal transmission modes such as isoSPI protocols, so that the bidirectional signal link of the present embodiment has good anti-interference ability and transmission distance. Specifically, the differential signal pair of the present embodiment can be connected by a twisted pair, and the characteristic impedance thereof is 120Ω.

[0036] It can be understood that, since each slave module 40 is connected to the next level slave module 40 through a bidirectional signal link, each slave module 40 needs to be connected to the next level slave module 40 through a specific interface and to the next level slave module 40 through another specific interface. Therefore, further in the aspect of hardware connection, each slave module 40 comprises a first signal interface, a second signal interface, a response control circuit and a signal transmission switch, wherein the first signal interface is used to connect to the next level node, and the second signal interface is used to connect to the next level node.

[0037] Specifically, the first signal interface comprises a first input end 431 for receiving the addressing signal and a first output end 432 for outputting the response signal. In the embodiment, the first input end 431 is connected to the output end of the next level node (which can be the master control unit 10 or the last slave module 40), and the first output end 432 is connected through the reverse signal line 22 for feeding back the response signal to the master control unit 10.

[0038] Similarly, the second signal interface comprises a second output end 441 for sending the addressing signal to the next level node and a second input end 442 for receiving the signal from the next level node.

[0039] The response control circuit is used to generate and send the response signal after receiving the addressing signal. It can be understood that, in the embodiment, the response control circuit is integrated in the microcontroller of the slave controller 42, detects the arrival of the addressing signal through the GPIO port and controls the level state of the reverse signal line 22.

[0040] Specifically, each slave module 40 generates the response signal by changing the electrical state of the reverse signal line 22, which includes pulling the reverse signal line 22 to low level or pulling the reverse signal line 22 to high level. In the embodiment, the reverse signal line 22 is in a default high level, and the slave module 40 pulls the reverse signal line 22 to low level as the response signal after receiving the addressing signal, and releases it after maintaining for about 10 ms. The maintaining time is set according to actual needs and is not limited herein.

[0041] The signal transmission switch is arranged between the signal output end of the slave module 40 and the second signal interface, and is used to be disconnected to prevent the addressing signal from being transmitted to the next level during the generation of the response signal and to be connected to allow the addressing signal to be transmitted to the next level after the slave module 40 receives the identification address.

[0042] It can be understood that in the embodiment, the signal transfer switch is implemented by an analog switch chip and is controlled by the GPIO port of the microcontroller. When the addressing signal is received from the slave module 40, the analog switch is immediately turned off to prevent the addressing signal from continuing to pass down; after the identification address distributed by the master control unit 10 is received through the CAN bus and stored, the analog switch is turned on again to allow the addressing signal to pass to the next slave module 40.

[0043] In the basic embodiment, the head end of the bidirectional signal link is connected to the master control unit 10, and the tail end is terminated by a matching resistance. In the embodiment, the tail end (i.e. the second signal interface output end of the last slave module 40) is terminated to the ground through a 120Ω matching resistance 50, which matches the characteristic impedance of the differential signal pair and effectively eliminates signal reflection, ensuring signal integrity. This open link structure is suitable for application scenarios where the number of modules is relatively fixed and the requirement for redundancy is not high.

[0044] In the preferred embodiment, the plurality of slave modules 40 are connected in series, and the nodes at the head and tail are connected through a redundant bidirectional signal link to form a ring topology with redundant paths. The addressing signal passes between the plurality of slave modules 40 in a first direction (e.g. clockwise), and the response signal passes in a second direction opposite to the first direction (e.g. counterclockwise). When a path fails, the master control unit 10 continues the addressing process through another path. In this ring topology, the master control unit 10 has two sets of bidirectional signal link interfaces, which are connected to the first slave module 40 and the last slave module 40 respectively, forming a closed loop. At this time, there is no need to set a matching resistance 50 at the tail end, because the ring structure itself does not have an open end. Normally, the master control unit 10 sends the addressing signal from the first set of interfaces; when a path failure is detected, it automatically switches to the second set of interfaces to continue the addressing process in the opposite direction, ensuring high reliability of the system. This redundant ring topology is suitable for critical application scenarios where high system reliability is required.

[0045] In terms of functional modules, the master control unit 10 of the embodiment includes a signal chain control module 11, a data communication control module 12, and an address allocation module 13. The signal chain control module 11 is used to manage the sending of the addressing signal and the receiving of the response signal of the bidirectional signal link.

[0046] It can be understood that in the embodiment, the signal chain control module 11 is implemented by a timer of the microprocessor, which is used to generate a fixed period (e.g. 50ms) addressing signal pulse, and a GPIO port, which is used to detect the response signal on the reverse signal line 22. The signal chain control module 11 is also responsible for timeout monitoring, and if the response signal is not received within a predetermined time (e.g. 100ms), it is determined that there is a fault.

[0047] The data communication control module 12 is configured to manage data transmission of the data communication link 30. In the embodiment, the data communication control module 12 is implemented based on a CAN bus controller, and is responsible for packaging, sending, receiving and analyzing CAN messages. The data communication control module 12 supports standard frame and extended frame formats, and the message identifier is encoded in the form of a combination of address code and function code.

[0048] The address allocation module 13 is configured to allocate a continuously increasing identification address to the corresponding slave module 40 according to the time sequence of the received response signals, and synchronize the address mapping relationship to the data communication control module 12. In the embodiment, the address allocation module 13 maintains an address counter with an initial value of 1. Upon receiving a response signal, the address counter is incremented by 1, and the current address value is broadcast to all slave modules 40 through the CAN bus. Since only the slave module 40 that is currently responding has its signal transmission switch in the open state, the slave module 40 can confirm that the address is allocated to itself. After the address allocation is completed, the address allocation module 13 stores the mapping relationship between the identification address and the hardware unique identifier in a non-volatile memory, and synchronizes it to the data communication control module 12 for subsequent data communication.

[0049] Preferably, the master control unit 10 also monitors the reception state of the response signals, and determines that there is a faulty node at the current position when the master control unit 10 does not receive a response signal within a preset timeout period, and records the number of slave modules 40 that have successfully received the response signals as the position of the faulty node in the addressing sequence and terminates the addressing process.

[0050] It can be understood that the preset timeout period of the embodiment can be set to 100 ms. If the master control unit 10 does not receive a response signal within 100 ms after sending the addressing signal, it is determined that there is a faulty node in the link, the number of addresses that have been allocated is recorded, the position of the faulty node in the addressing sequence is marked, the fault information is reported through the wireless communication module, and the addressing process is terminated. Maintenance personnel can quickly locate the problem module according to the fault position information. Of course, the preset timeout period needs to be set according to actual needs, which is not limited herein.

[0051] Preferably, the response signal generated by each slave module 40 carries the hardware unique identifier of the slave module 40, and the master control unit 10 can extract the hardware unique identifier and establish a mapping relationship between the identification address and the hardware unique identifier to verify the correctness of the addressing.

[0052] It can be understood that, in order to accurately identify each slave module 40, the microcontroller of each slave controller 42 of the embodiment has a unique UID, and therefore each slave module 40 has a unique hardware unique identifier. When generating a response signal, the slave module 40 transmits the UID information by modulating the reverse signal line 22. After receiving the response signal, the master control unit 10 decodes the UID information to establish a mapping relationship between the identification address and the UID.

[0053] Further, in subsequent system operation, the master control unit 10 can periodically request each slave module 40 to report the UID through the CAN bus, compare with the stored mapping relationship, and verify the correctness of the addressing. If it is found that the UID corresponding to a certain address has changed, it means that the module at this position has been replaced, and the system can automatically readdress or prompt the maintenance personnel.

[0054] The automatic addressing process of the embodiment is triggered after the system power initialization phase or receiving the addressing instruction of the master control unit 10, and is completely completed on the bidirectional signal link, which is isolated from the CAN bus to avoid conflicts. The specific process is as follows: Step 1, reset and ready: The master control unit 10 first sends a reset pulse (a low-level signal lasting about 20 ms) to the head end of the bidirectional signal link. The reset pulse is transmitted to all slave modules 40 in sequence along the forward signal line 21. After receiving the reset pulse, each slave module 40 resets its internal temporary address counter, turns off the signal transmission switch, and enters the addressing listening state. At this time, the identification address of all slave modules 40 is in an unallocated state.

[0055] Step 2, address application and distribution (bidirectional handshake): The master control unit 10 sends an addressing signal (about 5 ms of high-level pulse). After receiving the addressing signal, the first slave module 40 closest to the master control unit 10 on the bidirectional signal link immediately performs the following operations: 2.11, turn off the signal transmission switch of the second signal interface to prevent the addressing signal from being transmitted downstream; 2.12, pull down the reverse signal line 22 to low level for about 10 ms to send a response signal to the master control unit 10; 2.13, modulate and encode the hardware unique identifier of the slave module 40 in the response signal.

[0056] After receiving the response signal of the slave module 40 through the reverse signal line 22, the master control unit 10 processes as follows: 2.21, decode and extract the hardware unique identifier; 2.22, assign identification address 1 to the slave module 40; 2.23 Broadcast an address assignment command frame through the CAN bus, the frame content contains the assigned address value.

[0057] After receiving the address assignment command from the slave module 40 through the CAN bus, the identification address is stored in the non-volatile memory of the slave module 40, and the signal transmission switch of the second signal interface is turned on to allow the addressing signal to continue to pass downstream.

[0058] Step 3, link progression: After receiving the signal transmission switch from the slave module 40, the master control unit 10 sends the next addressing signal. The addressing signal is transmitted to the next slave module 40 through the slave module 40 that has completed addressing. After receiving the addressing signal, the next slave module 40 repeats the operation of step 2: turn off the signal transmission switch, send the response signal, receive the address assigned by the master control unit 10 through the CAN bus, and turn on the signal transmission switch after storing the address.

[0059] This process is repeated until the last slave module 40 at the end of the chain completes the addressing. In this embodiment, the total time for the addressing process of the 3 slave modules 40 is about 300 ms.

[0060] Step 4, completion and verification of addressing: After sending the addressing signal, if the master control unit 10 does not receive a response signal within the timeout time (100 ms), it means that there are no more slave modules 40, and the addressing process naturally ends. The master control unit 10 records the number of slave modules 40 that have completed this time.

[0061] Subsequently, the master control unit 10 polls each slave module 40 through the CAN bus, requests to report the current identification address and hardware unique identifier, and verifies the correctness of the addressing result. If a slave module 40 does not respond or the hardware unique identifier does not match, the master control unit 10 records the abnormal information and can re-initiate the addressing process.

[0062] Fault handling: During step 3, if the master control unit 10 does not receive a response signal within the timeout time, it determines that there is a faulty node at the current position. The master control unit 10 records the number of slave modules 40 that have successfully been addressed, infers the position of the faulty node in the addressing sequence, terminates the addressing process, and reports the fault position information through the wireless communication module. Maintenance personnel can quickly locate the position of the faulty module for repair or replacement.

[0063] In a ring topology, when a forward path fault is detected, the master control unit 10 automatically switches to the reverse path and starts reverse addressing from the end of the chain, maximizing the availability of the system.

[0064] It is verified that the parallel battery management system 100 of the embodiment is used to perform 500 power-on addressing tests, and the results show that the addressing success rate is 100%, there is no address conflict phenomenon, and the average addressing time is 288 ms (3 modules). Compared with the manual dialing mode, the addressing time is shortened from about 10 minutes to 0.5 seconds, the efficiency is significantly improved, the address error rate is reduced from about 2% to 0. Compared with the unidirectional daisy chain mode, in the single point failure scenario, the embodiment can continue to complete the addressing through the ring redundancy path, and the system availability is significantly improved. Embodiment two

[0065] Referring to Figure 4 The remote upgrading method of the parallel battery management system 100 of the embodiment is suitable for the parallel battery management system 100 of the aforementioned embodiment one, and the method is used for cluster remote upgrading of firmware distributed in multiple slave modules 40. Through the mechanisms such as wireless communication module, intelligent decision based on version number, block transmission and verification, and whole network version consistency verification, the method realizes efficient and reliable cluster firmware upgrading, Figure 4 The flowchart of the remote upgrading method of the embodiment is shown.

[0066] In order to better understand the embodiment, the embodiment is described in detail in the specific application scenario of the aforementioned parallel energy storage system containing 3 battery modules, and it is assumed that the current firmware versions of the 3 slave modules 40 in the parallel energy storage system are v1.3.0, v1.1.5 and v1.2.0, and the target firmware version published by the cloud server 200 is v1.3.0.

[0067] The remote upgrading method of the parallel battery management system 100 of the embodiment includes the following steps: S1, the master control unit 10 obtains the upgrading firmware file from the remote server through the wireless communication module and stores it.

[0068] It can be understood that the wireless communication module integrated in the master control unit 10 of the embodiment establishes a secure connection (such as TLS) with the cloud server 200. The master control unit 10 sends a firmware version query request to the cloud server 200 regularly (such as every day, every week, every month in the early morning period) or when receiving a firmware version query trigger instruction issued by the user.

[0069] The cloud server 200 returns a response message to inform whether there is a new version available, and the response message includes the target version number, the file size, the file download address and information such as SHA-256 verification.

[0070] The master control unit 10 confirms that there is a new version and starts the download process. The upgrade file can be transmitted in packets through the HTTPS protocol or similar protocols, and each data packet contains at least a sequence number and a check code such as CRC16. The master control unit 10 receives the data packets in order, checks each data packet, sends an acknowledgement if the check is passed, and requests retransmission if the check fails.

[0071] After all data packets are received, the master control unit 10 calculates the check hash value of the entire file and compares it with the standard checksum provided by the cloud server 200: If they are completely consistent, the firmware file check is passed, and the firmware file is stored in the firmware cache area of the master control unit 10 memory; If the check fails, the master control unit 10 deletes the downloaded file, records an error log, and reports to the cloud through the wireless communication module; The master control unit 10 sets a retry mechanism, retries a maximum of 3 times, and aborts the upgrade process if all 3 retries fail, waiting for maintenance personnel to intervene.

[0072] S2, the master control unit 10 broadcasts an upgrade notification message through the communication network, and the upgrade notification message contains a target version identifier.

[0073] It can be understood that the master control unit 10 broadcasts an upgrade preparation command frame through the CAN bus after confirming that the firmware is downloaded and the check is passed. The CAN message uses an extended frame format, and the data field contains command code, target version number (major version number, minor version number, revision number), and firmware file size, etc.

[0074] The master control unit 10 sends the broadcast frame 3 times in a row to ensure that all online slave modules 40 can receive it. After sending is complete, the master control unit 10 starts a response timer and waits for responses from the slave modules 40.

[0075] S3, each slave module 40 compares the target version identifier with its corresponding current version identifier after receiving the upgrade notification message, and determines that it needs to be upgraded and sends an upgrade request to the master control unit 10 when the target version identifier is higher than the current version identifier, and remains silent when the target version identifier is lower than or equal to the current version identifier.

[0076] Each slave module 40 receives the upgrade preparation broadcast frame through the CAN bus, parses the frame content with the slave controller 42, and extracts the target version number.

[0077] The slave controller 42 reads the current firmware version identifier from its memory, which can be stored in the semantic version number format "major version number.minor version number.revision number", such as v1.3.0, v1.1.5, v1.2.0, etc.

[0078] Preferably, the process of comparing the target version identifier with the current version identifier by the slave module 40 comprises: extracting the major version number, the minor version number and the revision number in the target version identifier; preferentially comparing the major version number, further comparing the minor version number when the major version number is the same, and further comparing the revision number when both the major version number and the minor version number are the same.

[0079] Specifically, the version comparison step of the present embodiment is as follows: firstly comparing the major version number, and determining that an upgrade is needed if the target major version number is greater than the current major version number; further comparing the minor version number if the major version number is the same; further comparing the revision number if both the major version number and the minor version number are the same.

[0080] It should be noted that the slave module 40 determines that an upgrade is needed only when the target version number is higher than the current version number.

[0081] The slave module 40 determining that an upgrade is needed sends an upgrade request frame to the master control unit 10, and the frame content includes a command code, a module identifier address and a hardware unique identifier of the slave module 40.

[0082] The slave module 40 determining that an upgrade is not needed remains silent and does not send any response. Thus, by the agreed manner, the master control unit 10 only performs operation on the slave module 40 making a response.

[0083] The master control unit 10 listens to the CAN bus within the response timer time, receives and records all upgrade request frames, generates a list of modules to be upgraded, and considers the responses exceeding the response timer time as invalid responses.

[0084] S4, the master control unit 10 divides the upgrade firmware file into a plurality of data blocks after receiving the upgrade request and sends them to the slave module 40 requesting the upgrade in sequence, and each data block contains a block sequence number and a check value.

[0085] The master control unit 10 reads the firmware file in the firmware cache area, divides it into a plurality of data blocks according to a fixed size. Each data block is numbered from 0 and incremented, and in the present embodiment, the size of each data block can be set to 256 bytes / block.

[0086] Preferably, the check value is a cyclic redundancy check code. In the present embodiment, the CRC16 algorithm is used to calculate the check value of each data block.

[0087] The master control unit 10 sends the data blocks to each slave module 40 in the list of modules to be upgraded in sequence. The sending mode adopts unicast to avoid CAN bus conflict caused by broadcast mode.

[0088] The data field of the CAN data block transmission frame contains a command code, a data block sequence number, a data block check value and a data load. Since the single frame data field of the CAN bus is limited, each data block is split into multiple CAN frames for transmission.

[0089] The actual transmission process adopts a sliding window protocol for flow control. The master control unit 10 first sends a plurality of data blocks to one slave module 40, waits for an acknowledgement and then continues to send, sequentially completing the data transmission of all slave modules 40 to be upgraded.

[0090] S5. After each slave module 40 receives a data block, it checks the integrity of the data block according to the check value and sends an acknowledgement message containing the block sequence number to the master control unit 10 after the check is passed.

[0091] It can be understood that the slave controller 42 of each slave module 40 receives its own data block through the CAN bus. After the slave module 40 receives the data block header frame, it parses the block sequence number and check value and allocates a buffer for the data block.

[0092] Subsequently, the data load frame is received and spliced into a complete data block and stored in the RAM buffer.

[0093] After splicing is completed, the slave controller 42 calculates the check value of the data block and compares it with the check value in the data block header frame. If they are completely consistent, the check is passed and the data block is written from the RAM buffer to the firmware staging area of the memory.

[0094] After writing is completed, the slave module 40 immediately replies to the master control unit 10 with an acknowledgement message frame containing a command code, a confirmed data block sequence number and an acknowledgement status.

[0095] After the master control unit 10 receives the acknowledgement message, it records the transmission status of the data block as confirmed and continues to send the next data block.

[0096] If the check of the slave module 40 fails, the slave module 40 sets the acknowledgement status to a failure flag. After the master control unit 10 receives it, it marks the data block as to be retransmitted and re-sends it later.

[0097] Preferably, the master control unit 10 re-sends the data block if it does not receive an acknowledgement message within a preset timeout period. If the number of retransmissions exceeds a preset threshold, the corresponding slave module 40 is marked as upgrade failed and the master control unit 10 continues to send data blocks to other slave modules 40.

[0098] The preset timeout period of the present embodiment is set to 200 ms and the preset threshold is set to 3 times. Specifically, if the master control unit 10 does not receive an acknowledgement message within 200 ms after sending a data block, it is determined that the transmission has timed out and the data block is immediately retransmitted. If the retransmission fails for three times in succession, the master control unit 10 marks the slave module 40 as upgrade failure, records error log, and reports to the cloud through the wireless communication module.

[0099] The master control unit 10 no longer sends subsequent data blocks to the slave module 40, and instead continues to send data blocks to other slave modules 40, so as to ensure that the upgrade process will not be interrupted due to a single module failure.

[0100] S6, each slave module 40 calculates the overall check value after receiving all data blocks and compares it with the pre-stored standard check value, and performs the firmware update operation after the overall check passes.

[0101] After each slave module 40 receives and stores all data blocks (i.e. the firmware temporary storage area of the memory is full), the slave controller 42 calculates the overall check value for the entire firmware file.

[0102] Preferably, the overall check value is a hash value generated by a message digest algorithm, such as the SHA-256 algorithm used in this embodiment to calculate the hash value of the firmware data.

[0103] The calculated hash value is compared with the pre-stored standard check value. The standard check value is transmitted to each slave module 40 in the upgrade preparation broadcast frame of step S2. If the calculated hash value is exactly the same as the standard check value, the overall check passes.

[0104] Preferably, each slave module 40 backs up the current firmware to a backup storage area before performing the firmware update operation, and performs a self-checking program to verify the new firmware function after the firmware is updated. If the self-checking fails, the current firmware is restored from the backup storage area and the master control unit 10 is reported of the upgrade failure.

[0105] The memory of the present embodiment is a non-volatile memory, which is divided into three areas: current firmware running area, firmware temporary storage area and firmware backup area.

[0106] Before performing the firmware update operation, the slave controller 42 first copies the contents of the current firmware running area to the firmware backup area. After the backup is completed, the upgrade program is started, and the new firmware in the firmware temporary storage area is copied and overwritten to the firmware running area. After the copying is completed, the upgrade program sets a reset flag and restarts the slave controller 42.

[0107] After the slave controller 42 is restarted, the new firmware starts running. The startup code of the new firmware contains a self-checking program to verify whether the key functions are normal, including CAN bus communication test, AFE chip communication test and memory read-write test, etc.

[0108] If all self-checking passes, the slave controller 42 sends a firmware update success report frame to the master control unit 10.

[0109] If the self-test fails, it indicates a problem with the new firmware. The controller 42 automatically initiates the firmware recovery process: the upgrade program detects the self-test failure flag, copies the old firmware from the firmware backup area back to the firmware runtime area, resets the reset flag, and restarts the controller 42. After the old firmware runs, it sends a firmware update failure report frame to the main control unit 10, containing the failure reason code.

[0110] After receiving the firmware update failure report, the main control unit 10 records the upgrade status of the slave module 40 as failed and reports it to the cloud via the wireless communication module.

[0111] Verification process for the upgrade results of main control unit 10: After each slave module 40 completes the firmware update operation (the main control unit 10 receives reports of successful or failed firmware updates from all modules to be upgraded, or exceeds the preset waiting time), the main control unit 10 initiates the network-wide version consistency verification process.

[0112] The main control unit 10 broadcasts a version query command frame via the CAN bus, requesting all slave modules 40 (not only the modules to be upgraded, but also the modules that did not need to be upgraded before) to report the currently running firmware version identifier.

[0113] After receiving the query command, each slave module 40 reads the current firmware version number from the memory and replies to the master control unit 10 via the CAN bus. The data field of the reply frame contains the command code and the current version number (major version number, minor version number, and revision number).

[0114] The main control unit 10 collects all version reporting frames from the slave module 40 and compares the version number reported by each slave module 40 with the target version number.

[0115] If all version numbers of module 40 match the target version number, the main control unit 10 determines that the upgrade is successful and executes the following steps: (1) Record the upgrade success status and timestamp in the memory; (2) Send an upgrade success report to the cloud server 200 through the wireless communication module. The report includes system device identifier, target version number, upgrade time, and list of successful modules. (3) The upgrade was successful as indicated by the status indicator light.

[0116] If there are inconsistent version identifiers in module 40, the main control unit 10 determines that the upgrade has failed and executes the following exception handling procedure: (1) Record the upgrade failure status and the list of failed modules; (2) Report an upgrade failure report to the cloud server 200 via the wireless communication module, including detailed failure information; (3) Abnormality is prompted by a status indicator light; (4) The master control unit 10 can select automatic retry upgrade process or wait for manual intervention according to configuration.

[0117] It is verified that the result of firmware upgrade by the remote upgrade method of the embodiment shows that the complete upgrade process of a single 5-module system takes about 320 seconds on average, which is about 86% shorter than the traditional on-site upgrade method of each module (about 15 minutes for each module, and 45 minutes for 3 modules). The upgrade success rate is 96.8%, and the version consistency is 100%, which ensures the integrity and consistency of cluster upgrade. Through multiple safeguards such as block checking, retransmission mechanism, backup recovery, and full network verification, the system compatibility chaos caused by single-point upgrade failure is effectively avoided, and the operation and maintenance efficiency and reliability of the battery system are significantly improved.

[0118] As a summary, the core technical idea of the embodiment is that the master control unit 10 acts as an upgrade coordinator, obtains the latest firmware from the cloud server 200 through the wireless communication module, and then broadcasts the upgrade notification through the CAN bus. Each slave module 40 performs version comparison independently, and only the modules that need to be upgraded initiate a request to the master control unit 10. The master control unit 10 distributes firmware data in a block-by-block transmission and block-by-block confirmation manner to ensure transmission reliability. The slave module 40 performs overall verification and updates the firmware after receiving the complete firmware. Finally, the master control unit 10 verifies the version consistency of the entire network to ensure successful upgrade.

[0119] In combination Figures 1-4 , the present application has the following beneficial effects: On the one hand, the bidirectional signal link realizes the forward transmission of addressing signals and the reverse feedback of response signals, and in combination with the bidirectional handshake mechanism, the sequence and certainty of the addressing process are ensured, which fundamentally eliminates the address errors and conflicts caused by manual dialing or software competition, realizes fully automatic and conflict-free intelligent addressing, greatly improves the production efficiency and system reliability. On the other hand, the double-layer network architecture physically isolates the lower-layer addressing signal chain from the upper-layer data communication link 30, and is functionally specific, and through redundant path design, any node or cable failure will not cause system paralysis, and the signal can be transmitted through another path, which significantly improves the fault tolerance and availability of the system. On the other hand, the intelligent upgrade decision mechanism based on version number enables each slave module 40 to independently determine whether it needs to be upgraded, in combination with the block-by-block checking and confirmation data transmission process, ensuring the atomicity, consistency and transmission reliability of firmware update in large-scale battery systems, realizing efficient and reliable cluster remote upgrade, effectively avoiding system compatibility chaos caused by single-point upgrade failure, and significantly improving the intelligent level and operation stability of the battery system in the whole life cycle of production deployment, later maintenance and remote upgrade.

[0120] The above-described embodiments are only used to illustrate the technical solutions of the present application, but not to limit the present application; although the present application has been described in detail with reference to the foregoing embodiments, it should be understood by those skilled in the art that the technical solutions recorded in the foregoing embodiments can be modified, or some technical features thereof can be replaced by equivalent technical features; and these modifications or replacements 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 application.

Claims

1. A co-pack battery management system, characterized by, The application relates to a battery management system, which comprises a master control unit, a bidirectional signal link, a data communication link and a plurality of slave modules, the master control unit is a main controller of the battery management system, each slave module comprises a battery unit and a slave controller connected with the battery unit, the bidirectional signal link is used for bidirectional signal transmission between the master control unit and the plurality of slave modules, and the data communication link connects the master control unit and the plurality of slave modules. The master control unit sequentially sends an addressing signal to the plurality of slave modules through the bidirectional signal link, receives a response signal from the slave modules through the bidirectional signal link, allocates an identification address to the corresponding slave module based on the received response signal, and sends the allocated identification address to the corresponding slave module through the data communication link. Each slave module receives the addressing signal through the bidirectional signal link, feeds back a response signal to the master control unit through the bidirectional signal link after receiving the addressing signal, prevents the addressing signal from continuing to pass to the next-level slave module during generation of the response signal, allows the addressing signal to continue to pass to the next-level slave module after the slave module receives an identification address sent by the master control unit through the data communication link, and the master control unit uses the identification address to perform data communication with the slave module through the data communication link.

2. The parallel battery management system of claim 1, wherein, The bidirectional signal link comprises a forward signal line and a reverse signal line, the forward signal line is used for sequentially connecting the master control unit and the plurality of slave modules to transmit the addressing signal, and the reverse signal line is used for sequentially connecting the plurality of slave modules and the master control unit to transmit the response signal.

3. The parallel battery management system of claim 2, wherein, Each slave module generates the response signal by changing an electrical state of the reverse signal line, and the change of the electrical state comprises pulling the reverse signal line to a low level or pulling the reverse signal line to a high level.

4. The parallel battery management system of claim 2, wherein, Each slave module comprises a first signal interface for connecting an upper-level node, a second signal interface for connecting a next-level node, a response control circuit and a signal transmission switch, the first signal interface comprises an input end for receiving the addressing signal and an output end for outputting the response signal, the second signal interface comprises an output end for sending the addressing signal to the next-level node, and the response control circuit is used for generating and sending the response signal after receiving the addressing signal. The signal transmission switch is arranged between the signal output end of the slave module and the second signal interface, is turned off to prevent the addressing signal from passing to the next level during generation of the response signal, and is turned on to allow the addressing signal to pass to the next level after the slave module receives the identification address. A head end of the bidirectional signal link is connected with the master control unit, and a tail end is terminated through a matching resistor.

5. The parallel battery management system of claim 2, wherein, The forward signal line and the reverse signal line respectively comprise a differential signal pair, the bidirectional signal link is a differential signal link network, and the data communication link is a local area network bus.

6. The parallel battery management system of claim 5, wherein, The multiple slave modules are connected in series and the first and last nodes are connected by a redundant bidirectional signal link to form a ring topology with redundant paths, the addressing signal is transmitted between the multiple slave modules in a first direction, and the response signal is transmitted in a second direction opposite to the first direction, and when a path fails, the master control unit continues the addressing process through another path.

7. The parallel battery management system of claim 1, wherein, The master control unit comprises a signal link control module, a data communication control module and an address allocation module, the signal link control module is used for managing the transmission of the addressing signal and the reception of the response signal of the bidirectional signal link; The data communication control module is used for managing the data transmission of the data communication link; The address allocation module is used for allocating a continuously increasing identification address to the corresponding slave module according to the time sequence of the received response signal and synchronizing the address mapping relationship to the data communication control module.

8. The parallel battery management system of claim 1, wherein, The master control unit also monitors the reception state of the response signal, and when the master control unit does not receive the response signal within a preset timeout time, it is determined that there is a faulty node at the current position, the number of slave modules that have successfully received the response signal is recorded as the position of the faulty node in the addressing sequence, and the addressing process is terminated.

9. The parallel battery management system of claim 1, wherein, The response signal generated by each slave module carries a hardware unique identifier of the slave module, and the master control unit can extract the hardware unique identifier and establish a mapping relationship between the identification address and the hardware unique identifier to verify the correctness of the addressing.

10. A remote upgrading method of a parallel battery management system, the system comprising a master control unit, a communication network and a plurality of slave modules, each of the slave modules storing a current version identification, the method comprising: receiving (S101) a new version identification from the master control unit; determining (S102) whether the new version identification is different from the current version identification; and if the new version identification is different from the current version identification, updating (S103) the current version identification to the new version identification. The remote upgrading method of the parallel battery management system comprises the following steps: The master control unit obtains an upgrading firmware file from a remote server through a wireless communication module and stores it; The master control unit broadcasts an upgrading notification message through the communication network, and the upgrading notification message contains a target version identifier; Each slave module compares the target version identifier with its corresponding current version identifier after receiving the upgrading notification message, and when the target version identifier is higher than the current version identifier, the slave module determines that it needs to be upgraded and sends an upgrading request to the master control unit, and when the target version identifier is lower than or equal to the current version identifier, the slave module remains silent; After receiving the upgrading request, the master control unit divides the upgrading firmware file into multiple data blocks and sends them to the slave modules requesting upgrading in sequence, each data block contains a block serial number and a check value; After each slave module receives each data block, it checks the integrity of the data block according to the check value, and sends a confirmation message containing the block serial number to the master control unit after passing the check; After each slave module receives all the data blocks, it calculates an overall check value and compares it with a pre-stored standard check value, and performs a firmware update operation after passing the overall check.

11. The method of remote upgrading of claim 10, wherein, The check value is a cyclic redundancy check code, the overall check value is a hash value generated by a message digest algorithm, and the process of comparing the target version identifier with the current version identifier by each slave module comprises: Extracting the major version number, minor version number and revision number in the target version identifier; The main version number is compared preferentially, the secondary version number is further compared when the main version number is the same, and the revision number is further compared when the main version number and the secondary version number are both the same.

12. The method of remote upgrading of claim 10, wherein, The master control unit retransmits the data block when no acknowledgement message is received within a preset timeout period, and marks the corresponding slave module as upgrade failure and continues to send the data block to other slave modules when the number of retransmissions exceeds a preset threshold; Each slave module backs up the current firmware to a backup storage area before performing the firmware update operation, verifies the new firmware function by performing a self-checking program after the firmware is updated, recovers the current firmware from the backup storage area and reports the upgrade failure to the master control unit when the self-checking fails.

13. The method of remote upgrading of claim 10, wherein The master control unit requests all slave modules to report the current version identifier through the communication network after the firmware update operation is completed, and compares all received version identifiers with the target version identifier; The upgrade is determined to be successful when the version identifiers of all slave modules are consistent with the target version identifier; The upgrade failure is recorded and an abnormal processing procedure is triggered when there is a slave module with an inconsistent version identifier.

Images