A distributed battery management system based on bluetooth ad hoc network

Abstract

The utility model discloses a kind of distributed battery management system based on bluetooth ad hoc network belongs to battery management system BMS field.High-voltage battery panel contains a WBMS mainboard, multiple WBMS slave boards, battery module, thermal management component and structural member, each battery module is bound with independent WBMS slave board, mainboard is established distributed communication topology with slave board through 2.4GHz BLE Mesh, provides standard charge and discharge and CAN communication interface to outside.WBMS mainboard carries multi-core heterogeneous bluetooth SOC chip, WBMS chip of WBMS slave board is formed by SIP by vehicle level AFE and low-power-consumption bluetooth SOC, AFE collects battery voltage, temperature and other data, BLE part realizes battery module MESH networking cascade, after data summarization, access automobile electric control and power system through CAN bus.This system optimizes space design, reduces cost, improves reliability, and guarantees real-time accurate interaction of data.

Description

Technical Field

[0001] This utility model relates to a distributed battery management system based on Bluetooth self-organizing network, belonging to the field of BMS battery management technology. Background Technology

[0002] Currently, the total voltage of the power battery panels of new energy pure electric vehicles on the market is usually between 400V and 600V. The entire battery panel is generally composed of 10 to 20 battery modules cascaded together. The total voltage of a single battery module is about 36V to 48V. Multiple battery modules are cascaded and communicate with each other in a daisy-chain topology using cables.

[0003] This traditional battery cascading scheme has the following three main drawbacks: (1) The cable harnesses and communication isolation components used for cascading occupy a large portion of the battery space, reducing the energy density of the battery panel. (2) A large number of connectors increase the installation complexity and maintenance cost of the battery panel. (3) The risk of failure caused by a large number of connectors has a significant impact on the reliability of the entire battery panel.

[0004] The present invention aims to provide a distributed battery management system based on Bluetooth self-organizing network, which can effectively solve the above problems. Summary of the Invention

[0005] The purpose of this invention is to address the shortcomings of existing battery cascading solutions in the field of new energy electric vehicles and to provide a distributed battery management system based on Bluetooth self-organizing networks.

[0006] The technical solution of this utility model is: a high-voltage battery board for new energy electric vehicles, comprising a WBMS main board, multiple WBMS slave boards, multiple battery modules, several thermal management components and structural parts. Each battery module is connected and bound to an independent WBMS slave board through a data acquisition line. The WBMS main board and the WBMS slave boards establish a distributed communication topology through a 2.4GHz BLE Mesh to achieve high-efficiency wireless data transmission and command interaction, and provide a standard charging and discharging interface and a CAN communication interface for the power / electric control system.

[0007] A further technical solution is that the WBMS motherboard includes a Bluetooth SOC chip that supports BLE Mesh. This chip adopts a multi-core heterogeneous communication architecture. Its main core is an Open CPU application processor that runs the Bluetooth protocol stack and application programs, while the auxiliary core is a baseband processor that handles RF link-related functions.

[0008] A further technical solution involves the WBMS slave board containing a WMBS chip, which is a combination of an automotive-grade analog front-end (AFE) and a low-power Bluetooth SoC packaged together via SIP, enabling the acquisition and monitoring of battery status data and wireless communication.

[0009] Further technical solutions include a high-precision Sigma-Delta ADC in the AFE section of the WMBS chip, a battery passive balancing drive circuit that supports parity balancing, a charging and discharging NMOS drive circuit compatible with both high and low sides, a battery charging and discharging and high and low temperature protection circuit, a fault detection circuit, a serial communication module, and an NTC temperature detection port.

[0010] A further technical solution is that the BLE part of the WMBS chip is a complete low-power Bluetooth SoC with strong anti-interference capabilities, which runs a Bluetooth protocol stack and WBMS node service program, supports at least 32 MESH nodes to network and communicate simultaneously. The MESH nodes are battery modules, realizing wireless interaction applications of battery data and control commands.

[0011] A further technical solution involves the application processor on the WBMS motherboard establishing a distributed wireless self-organizing network using BLE Mesh technology. This network receives status frame data periodically reported from each WBMS slave board. After data frame decoding, processing, cleaning, and summarization, the processor extracts the status data that has undergone valid changes, encapsulates it into CAN data frames, and then forwards them to the ECU via the CAN interface.

[0012] A further technical solution involves the WBMS node service program on the board reading the voltage, temperature, and fault alarm status data of the connected battery modules according to a preset polling cycle, encapsulating them into different types of status frames, and actively reporting them to the WBMS main board at different update frequencies based on the priority order of each status type.

[0013] A further technical solution involves the WBMS node service program on the board responding in real time to command frame requests sent from the WBMS motherboard. By parsing different command protocols, it can query or modify parameters such as battery protection thresholds, battery passive balancing control, charging and discharging MOS drive, message priority, and reporting cycle parameters. The battery protection thresholds include voltage thresholds and delay thresholds. After each command request is executed, a corresponding response frame returns the operation result.

[0014] A further technical solution is that all wireless communication frames, whether initiated by the WBMS motherboard or the WBMS slave board, including request frames and response frames, consist of a frame header identifier field, a command word, an auto-incrementing command sequence ID, a response sequence ID, a frame length field, a compressed and AES-encrypted payload data segment, and a 16-bit CRC checksum. The status data frames automatically reported by the WBMS slave board do not require a response, and the remaining command frames are in the form of one request frame followed by one response frame.

[0015] A further technical solution is that when the WBMS motherboard or the WBMS application receives an instruction request frame, it must first verify the frame header identifier field and the frame tail check field. Only after all verifications are passed will the frame be further parsed and processed according to the instruction word and data segment, and a response frame will be returned. Otherwise, if any verification fails, the request frame will be discarded directly without any response processing.

[0016] A further technical solution involves the WBMS motherboard or WBMS slave board application receiving a command response frame. In addition to verifying the frame header identifier field and the frame trailer check field, it also verifies whether the command word and response serial number ID are consistent with the command word and auto-incrementing command serial number ID of the sent request frame. Only after all verifications are passed can a valid response frame be determined to have been received, and subsequent business logic can be further processed based on the response result. Otherwise, the request frame will be resent after the response timeout, and the auto-incrementing command serial number ID and retry counter of the request frame will be incremented by 1. If a valid response frame is still not received before the number of retries exceeds the set limit, a request failure is returned, and a communication fault error is reported.

[0017] In a further technical solution, the number of retries and the response timeout in the command frame request and response mechanism can be specified by configuration parameters or dynamically modified by configuration commands, and the calculation formula for the response timeout after each retry is T. N+1 =T N ×(N+1), where T N+1 Indicates the timeout period for the response after each retransmission, in seconds; T N The timeout period for the previous response is indicated in seconds; N represents the count value of the retry counter, in times.

[0018] The beneficial effects of this utility model are as follows: Firstly, it optimizes space design. Compared to traditional daisy-chain-based wired battery pack cascading solutions, the wireless BMS eliminates traditional physical wiring harnesses, resulting in a more compact design that frees up more space for the battery panels, significantly improving energy density and space utilization. Secondly, it offers significant cost advantages, reducing cable harnesses, connectors, and isolation components, greatly lowering material costs, and simplifying system installation and maintenance. Finally, in terms of reliability, wireless communication effectively reduces the risk of wiring harness aging and connector failure. Furthermore, the distributed topology enhances the system's resistance to single-point failures, minimizing the impact of single-point failures on the overall system, unlike the daisy-chain wired approach which can lead to complete communication paralysis. In addition, the BLE high-speed wireless communication protocol ensures real-time monitoring and rapid response capabilities. Its low latency characteristic keeps data transmission delays within milliseconds, far superior to the wired communication methods of traditional BMS. Attached Figure Description

[0019] Figure 1This is a block diagram of the wireless battery cascading system of this utility model.

[0020] Figure 2 This is a block diagram of the WBMS slave board system of this utility model.

[0021] Figure 3 This is a schematic diagram of the core module structure of the AFE part of this utility model.

[0022] Figure 4 This is a diagram of the BLE Mesh distributed networking communication topology of this utility model.

[0023] Figure 5 This is a flowchart of the BLE Mesh application of this utility model. Detailed Implementation

[0024] The technical solution of this utility model will be further described in detail below through embodiments and in conjunction with the accompanying drawings.

[0025] This utility model relates to a distributed battery management system based on a Bluetooth self-organizing network, such as... Figure 1 As shown, the power battery pack of the new energy electric vehicle chassis consists of N battery modules connected in series to form a 400V~600V high-voltage battery pack, which supplies power externally through the BAT- and BAT+ terminals. Within the battery pack space, there is an equal number of WBMS slave boards as the battery modules. These WBMS slave boards are mesh nodes and also include several thermal management components and structural parts. Each battery module is connected and bound to an independent WBMS slave board via a data acquisition line. Outside the battery pack space, a WBMS main board is installed. This WBMS main board is the master control unit. The WBMS main board and the WBMS slave boards establish a distributed communication topology through a 2.4GHz BLE Mesh, enabling high-efficiency wireless data transmission and command interaction. Furthermore, the WBMS main control board provides a standard CAN interface for communication between ECUs.

[0026] The WBMS motherboard, also known as the central control unit, is the core of the entire distributed battery management system. It can manage up to 100 battery modules simultaneously via a BLEMesh self-organizing network, forming a complete wireless battery pack management system. The WBMS motherboard includes a Bluetooth SoC chip that supports BLE Mesh. This chip employs a multi-core heterogeneous communication architecture. Its main core is an Open CPU application processor running the Bluetooth protocol stack and applications; the secondary core of the Bluetooth SoC is a baseband processor handling RF link-related functions to achieve RF wireless communication.

[0027] The WBMS slave board is used to manage individual battery modules and is a network node in a distributed battery management system. For example... Figure 2As shown, the WBMS slave board contains a WMBS chip, which is packaged using a SiP method with an automotive-grade analog front-end (AFE) and a low-power Bluetooth SoC. This enables the acquisition and monitoring of battery status data and wireless communication. The AFE portion of the WMBS chip, known as the analog front-end, is responsible for sampling and monitoring parameters such as battery voltage, current, and temperature. Its functional modules are as follows: Figure 3 As shown, it includes a high-precision Sigma-Delta ADC, a battery passive equalization drive circuit that supports parity equalization, a charging and discharging NMOS drive circuit compatible with both high and low sides, a battery charging and discharging and high and low temperature protection circuit, a fault detection circuit, a serial communication module, and an NTC temperature detection port.

[0028] The WBMS motherboard and numerous WBMS slave boards establish a distributed many-to-many communication topology via a 2.4GHz BLE Mesh, enabling highly efficient wireless data transmission and command interaction. For example... Figure 4 As shown, the WBMS motherboard and all WBMS slave boards are nodes in the BLE Mesh network. Each Mesh node has wireless repeater characteristics and can forward received messages. It is responsible for extending the network coverage. The transmitted messages hop across multiple nodes and eventually cover the entire Mesh network, realizing the uplink and downlink of messages.

[0029] The application on the WBMS motherboard receives battery status frame data reported periodically from each WBMS slave board via the BLE Mesh network. After decoding, organizing, cleaning, and summarizing the data frames, it extracts the status data that has changed effectively, encapsulates it into CAN data frames, and forwards them to the ECU via the CAN interface.

[0030] The WBMS node service program on the board reads the voltage, temperature, and fault alarm status data of the connected battery modules according to the preset polling cycle, encapsulates them into different types of status frames, and actively reports (sends) them to the WBMS motherboard at different update frequencies according to the priority order of each status type.

[0031] Figure 5 The diagram shown is a common wireless communication block diagram for both the WBMS motherboard and WBMS slave board. The process begins with system initialization, followed by BLE initialization and the BLE Mesh network setup. Next, the system enters the run_loop event loop, waiting for various event flags. Upon receiving a command frame request, further frame parsing and processing are required, and a response must be provided. The WBMS slave board nodes must collect the battery module's voltage, current, and temperature information when a timed event arrives and send it to the WBMS motherboard node.

[0032] All wireless communication frames, whether request or response frames initiated by the WBMS motherboard or the WBMS slave board, have the same format, as shown in the table below: MagicWord 2 Frame header identifier, marking the start of a frame of data. SyncID 2 Auto-increment instruction serial ID AckID 2 Response Serial ID Command 1 Instruction words identify different instructions. Payload_Len 1 The frame length field indicates the length of the payload data. Payload_Data Payload_Len Payload data segments encrypted and compressed using AES CRC16 2 16-bit CRC check bits

[0033] Each instruction status frame includes a frame header identifier field, instruction word, auto-incrementing instruction sequence ID, response sequence ID, frame length field, a payload data segment encrypted and compressed using AES, and a 16-bit CRC checksum. Except for the status data frames automatically reported by the WBMS slave board, which do not require a response, all other instruction frames are in the form of request plus response.

[0034] The WBMS node service program on the slave board responds in real time to the instruction frame requests sent from the WBMS motherboard. By parsing different instruction protocols, it can query or modify parameters such as battery protection threshold (voltage and delay), battery passive balancing control, charging and discharging MOS drive, message priority, and reporting cycle. After each instruction request is executed, a corresponding response frame returns the operation result.

[0035] When the application on the WBMS motherboard or WBMS slave board receives a command request frame, it must first verify the frame header identifier field and the frame trailer checksum field. Only after all verifications pass will it proceed to further parse and process the command word and data segment, and return a response frame. Otherwise, if any verification fails, the request frame will be discarded without any response processing. When the application on the WBMS motherboard or WBMS slave board receives a command response frame, in addition to verifying the frame header identifier field and the frame trailer checksum field, it must also verify whether the command word and response serial number ID are consistent with the command word and auto-incrementing command serial number ID of the sent request frame. Only after all verifications pass can a valid response frame be considered received, and subsequent business logic can be processed based on the response result. Otherwise, the request frame will be resent after the response timeout, and the auto-incrementing command serial number ID and retry counter of the request frame will be incremented by 1. If a valid response frame is not received before the number of retries exceeds the set limit, a request failure will be returned, and a communication fault error will be reported.

[0036] In the command frame request and response mechanism, the number of retries and the response timeout can be specified by configuration parameters or dynamically modified by configuration commands, and the formula for calculating the response timeout after each retry is T. N+1 =T N ×(N+1), where T N+1 Indicates the timeout period for the response after each retransmission, in seconds; T N The timeout period for the previous response is indicated in seconds; N represents the count value of the retry counter, in times.

Claims

1. A distributed battery management system based on Bluetooth self-organizing network, characterized in that, The entire high-voltage battery pack contains a WBMS main board, multiple WBMS slave boards, multiple battery modules, several thermal management components and structural parts. Each battery module is connected and bound to an independent WBMS slave board via a data acquisition line. The WBMS main board and slave boards establish a distributed communication topology through a 2.4GHz BLE Mesh to achieve high-efficiency wireless data transmission and command interaction. It also provides a standard charging and discharging interface and a CAN communication interface to the power / electronic control system.

2. The distributed battery management system based on Bluetooth self-organizing network according to claim 1, characterized in that, The WBMS motherboard includes a Bluetooth SOC chip that supports BLE Mesh. This chip adopts a multi-core heterogeneous communication architecture. Its main core is an Open CPU application processor that runs the Bluetooth protocol stack and application programs, while the auxiliary core is a baseband processor that handles RF link-related functions.

3. A distributed battery management system based on Bluetooth ad hoc networking according to claim 1, characterized in that, The WBMS slave board contains a WMBS chip, which is packaged from an automotive-grade analog front-end (AFE) and a low-power Bluetooth SoC via SIP, enabling the acquisition and monitoring of battery status data and wireless communication.

4. A distributed battery management system based on Bluetooth ad hoc networking according to claim 2, characterized in that, The application processor establishes a BLE Mesh wireless self-organizing network communication, receives status frame data reported periodically from each WBMS slave board, and after data frame decoding, sorting, cleaning and summarizing, extracts the status data that has undergone effective changes, encapsulates it into CAN data frames and forwards it to the ECU through the CAN interface.

5. A distributed battery management system based on Bluetooth ad hoc networking according to claim 3, characterized in that, The AFE section of the WBMS chip includes a high-precision Sigma-Delta ADC, a battery passive equalization drive circuit that supports parity equalization, a charging and discharging NMOS drive circuit compatible with both high and low sides, a battery charging and discharging and high and low temperature protection circuit, a fault detection circuit, a serial communication module, and an NTC temperature detection port.

6. A distributed battery management system based on Bluetooth ad hoc networking according to claim 3, characterized in that, The BLE portion of the WBMS chip is a complete, low-power Bluetooth SoC with strong anti-interference capabilities. It runs a Bluetooth protocol stack and WBMS node service program, supporting simultaneous networking and communication of at least 32 MESH nodes. The MESH nodes are battery modules, enabling wireless interaction between battery data and control commands.

7. A distributed battery management system based on Bluetooth ad hoc networking according to claim 6, characterized in that, The WBMS node service program reads the voltage, temperature, and fault alarm status data of the battery modules it is connected to according to a preset polling cycle, encapsulates them into different types of status frames, and actively reports them to the WBMS motherboard at different update frequencies according to the priority order of each status type.

8. A distributed battery management system based on Bluetooth ad hoc networking according to claim 6, characterized in that, The WBMS node service program responds in real time to the instruction frame requests sent from the WBMS motherboard. By parsing different instruction protocols, it can query or modify parameters such as battery protection threshold, battery passive balancing control, charging and discharging MOS drive, message priority, and reporting cycle. The battery protection threshold includes voltage threshold and delay threshold. After each instruction request is executed, a corresponding response frame returns the operation result.

9. A distributed battery management system based on Bluetooth ad hoc networking according to claim 4, 7, or 8, characterized in that, All wireless communication frame formats consist of a frame header identifier field, a command word, an auto-incrementing command sequence ID, an acknowledgment sequence ID, a frame length field, a payload data segment encrypted and compressed using AES, and a 16-bit CRC checksum. Status data frames automatically reported by the WBMS slave board do not require an acknowledgment, while other command frames are in the form of a request frame followed by an acknowledgment frame.

10. A distributed battery management system based on Bluetooth ad hoc networking according to claim 4, 7, or 8, characterized in that, When the WBMS motherboard or WBMS slave board receives a command request frame, it must first verify the frame header identifier field and the frame tail check field. Only after all verifications are passed will it proceed to further parse and process the command words and data segments and return a response frame. Otherwise, if any verification fails, the request frame will be discarded directly without any response processing.

11. A distributed battery management system based on Bluetooth ad hoc networking according to claim 4, 7, or 8, characterized in that, When the WBMS motherboard or WBMS slave board receives a command response frame, in addition to verifying the frame header identifier field and the frame trailer check field, it also verifies whether the command word and response serial number ID are consistent with the command word and auto-incrementing command serial number ID of the sent request frame. Only after all verifications are passed can it be determined that a valid response frame has been received, and subsequent business logic can be further processed based on the response result. Otherwise, the request frame will be resent after the response timeout, and the auto-incrementing command serial number ID and retry counter of the request frame will be incremented by 1. If the number of retries exceeds the set limit and a valid response frame is still not received, a request failure will be returned and a communication fault error will be reported.

12. A distributed battery management system based on Bluetooth ad hoc networking according to claim 11, characterized in that, The number of retries and the response timeout can be specified through configuration parameters or dynamically modified through configuration commands. The formula for calculating the response timeout after each retry is T. N+1 =T N ×(N+1), where T N+1 Indicates the timeout period for the response after each retransmission, in seconds; T N The timeout period for the previous response is indicated in seconds; N represents the count value of the retry counter, in times.

Images