Battery management system supporting multi-protocol communication

Abstract

This invention discloses a battery management system supporting multi-protocol parallel communication, relating to the field of battery management technology. It includes a host computer, a master unit, and at least one slave unit. The master unit is configured to: identify the first communication protocol used by the host computer; receive a first protocol request message from the host computer; parse the first protocol request message to extract the target slave unit identifier and operation information containing the characteristics of the first communication protocol; re-encapsulate the operation information into a downlink data frame according to the second communication protocol used for communication with the slave unit; and send the downlink data frame to the target slave unit. This invention extracts the first communication protocol characteristic information from the master unit and converts it into a second communication protocol frame, which is then sent to the slave unit. The slave unit parses the frame, executes it directly, and responds. The master unit then restores the response to the first communication protocol message and sends it back to the host computer, enabling the slave unit to directly respond to commands using different protocols, achieving cross-protocol transparent communication and low-latency data interaction.

Description

Technical Field

[0001] This invention relates to the field of battery management technology, and in particular to a battery management system that supports multi-protocol parallel communication. Background Technology

[0002] In energy storage power stations, electric vehicles, and other scenarios, battery management systems (BMS) often employ a multi-machine parallel approach to expand capacity. The system consists of a host computer, a master unit, and multiple slave units. Slave units manage their respective battery packs and collect parameters, while the master unit aggregates the data and uploads it to the host computer. Communication between the host computer and the master unit typically uses SNMP, Modbus, or serial MS protocols, while the master unit and slave units are networked via CAN or RS485 bus.

[0003] In existing parallel systems, the master node only acts as a data relay node and lacks the ability to perform real-time multi-protocol conversion and forwarding. When the host computer issues commands via application layer protocols such as SNMP and Modbus, the master cannot directly convert and forward the protocol data to the slave. The slave can only recognize low-level communication protocol frames and cannot recognize and respond to complex protocol commands containing features such as SNMP OIDs or Modbus function codes. This results in commands needing to be fully parsed and reassembled by the master before reaching the slave, increasing processing latency and reducing system real-time response. Furthermore, when the host computer changes the communication protocol, the slave cannot adapt, requiring synchronous modification of the master-slave communication logic, leading to poor protocol adaptability. In addition, the master's polling mechanism for slave data acquisition is highly coupled with the communication process for responding to the host computer; when the number of slaves increases or the protocol changes, the scheduling logic needs to be redesigned, resulting in poor system scalability and high maintenance costs. Summary of the Invention

[0004] The main objective of this invention is to provide a battery management system that supports multi-protocol parallel communication. This addresses the problem in existing parallel BMS systems where the host computer merely acts as a data relay node, lacking real-time multi-protocol conversion and forwarding capabilities. When the host computer issues commands via protocols such as SNMP and Modbus, the host cannot directly convert and forward the protocol data to the slave computer, and the slave computer cannot recognize and respond to complex protocol commands, resulting in high system response latency and poor protocol adaptability.

[0005] To achieve the above objectives, this invention proposes a battery management system supporting multi-protocol parallel communication, comprising a host computer, a master computer, and at least one slave computer. Each slave computer is connected to a group of batteries and is used to collect battery parameters of the connected batteries. The master computer communicates with each slave computer through a second communication bus and communicates with the host computer through a first communication interface. The system is characterized by: The host is configured to: identify the first communication protocol used by the host computer; receive a first protocol request message from the host computer, parse the first protocol request message to extract the target slave identifier and operation information containing the characteristics of the first communication protocol; re-encapsulate the operation information into a downlink data frame according to the second communication protocol used to communicate with the slave, and send the downlink data frame to the target slave; The slave device is configured to: receive downlink data frames, parse operation information corresponding to the first communication protocol feature from the downlink data frames, and perform local operations based on the parsed operation information; The host is also configured to: receive response frames returned by the slave, extract execution results from the response frames, encapsulate the execution results into a response message according to the first communication protocol, and return the response message to the host computer, so that the slave can directly respond to the instructions issued by the host computer according to the first communication protocol.

[0006] The slave device is also configured to: after performing a local operation, generate response data containing the execution result, encapsulate the response data into a response frame conforming to the second communication protocol, and return the response frame to the master device through the second communication bus; The host is also configured to: receive response frames returned by the slave, extract execution results from the response frames, encapsulate the execution results into a response message according to the first communication protocol, and return the response message to the host computer through the first communication interface, so that the slave can directly respond to the instructions issued by the host computer according to the first communication protocol.

[0007] Both the master and slave devices are equipped with address dialing codes. The master device determines itself as the master by reading its own address dialing code value as a preset master address value, and loads the protocol conversion scheduling module to perform protocol conversion and forwarding functions between the first communication protocol and the second communication protocol. The slave device determines itself as the slave by reading its own address dialing code value as a non-master address value, and loads the protocol adaptation execution module to perform parsing and local operation functions on downlink data frames.

[0008] The host is also configured to: during the power-on initialization phase, scan the address DIP switches of each slave device, automatically determine the number of slave devices and communication addresses based on the scanned DIP switch values, and dynamically establish a data polling list based on the number of slave devices and communication addresses; the host divides the data polling period T into N time slots according to the number of slave devices N, with each time slot corresponding to one slave device, and sends data request frames to each slave device in ascending order of address DIP switches.

[0009] The host computer has a protocol conversion scheduling module and a global data buffer. The protocol conversion and scheduling module is used to identify, parse, encapsulate, and forward protocol data between the first and second communication protocols. The host is also configured to: during idle periods when there is no instruction interaction with the host computer, periodically poll the real-time data of each slave through the second communication bus and store the acquired real-time data in the global data buffer; when it receives a query request for real-time data from the host computer, it directly reads the real-time data from the global data buffer and encapsulates the real-time data into response data and sends it to the host computer.

[0010] The operation information extracted by the host from the first protocol request message includes the target OID field or function code of the first communication protocol; the slave device is equipped with a protocol adaptation execution module, which is used to parse the target OID field or function code from the received downlink data frame, and determine the corresponding operation type and operation parameters based on the parsed target OID field or function code.

[0011] When the host sends a downlink data frame, it encapsulates the target slave identifier in the frame header or address field of the downlink data frame and sends the downlink data frame to the target slave in a unicast manner. After receiving the downlink data frame, the slave compares the target slave identifier in the downlink data frame with its own address dialing to determine whether it is the target slave. If the result is yes, it performs parsing and response operations on the downlink data frame. If the result is no, it discards the downlink data frame.

[0012] The system consists of multiple hosts, each of which manages a group of slave devices and communicates independently with the host computer. Each host connects to and manages at least one slave device, and each host communicates independently with the host computer, forming a multi-host parallel architecture. The host computer interacts with each host through a unified first communication protocol, and each host interacts with its connected slave devices through its own second communication bus.

[0013] The second communication bus between the master and each slave device adopts the CAN bus, and there is also a redundant backup second communication bus between the master and each slave device. When the master bus fails, the system automatically switches the communication to the backup bus to continue communication.

[0014] After parsing the first protocol request message, the host establishes and maintains a protocol mapping table. The protocol mapping table records the correspondence between the characteristic fields of the first communication protocol and the frame identifier of the second communication protocol. After receiving the response frame returned by the slave, the host restores the response frame into a response message that conforms to the first communication protocol according to the correspondence recorded in the protocol mapping table.

[0015] This invention extracts the first communication protocol feature information from the host and converts it into a second communication protocol frame, which is then sent to the slave device. The slave device parses the frame, executes it directly, and responds. The host then restores the response to the first communication protocol message and sends it back to the host computer, enabling the slave device to directly respond to commands of different protocols and achieving cross-protocol transparent communication and low-latency data interaction. Attached Figure Description

[0016] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with the invention and, together with the description, serve to explain the principles of the invention.

[0017] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0018] Figure 1 This invention provides an architecture diagram of a battery management system that supports multi-protocol parallel communication.

[0019] The objectives, features, and advantages of this invention will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0020] It should be understood that the specific embodiments described herein are merely illustrative of the technical solutions of the present invention and are not intended to limit the present invention.

[0021] To better understand the technical solution of the present invention, a detailed description will be provided below in conjunction with the accompanying drawings and specific embodiments.

[0022] A battery management system supporting multi-protocol parallel communication includes a host computer, a master computer, and at least one slave computer. Each slave computer is connected to a group of batteries and is used to collect battery parameters of the connected batteries. The master computer communicates with each slave computer through a second communication bus and communicates with the host computer through a first communication interface. The system is characterized by: The host is configured to: identify the first communication protocol used by the host computer; receive a first protocol request message from the host computer, parse the first protocol request message to extract the target slave identifier and operation information containing the characteristics of the first communication protocol; re-encapsulate the operation information into a downlink data frame according to the second communication protocol used to communicate with the slave, and send the downlink data frame to the target slave; The slave device is configured to: receive downlink data frames, parse operation information corresponding to the first communication protocol feature from the downlink data frames, and perform local operations based on the parsed operation information; The host is also configured to: receive response frames returned by the slave, extract execution results from the response frames, encapsulate the execution results into a response message according to the first communication protocol, and return the response message to the host computer, so that the slave can directly respond to the instructions issued by the host computer according to the first communication protocol.

[0023] In this embodiment, the system includes a host computer, a master unit, and at least one slave unit. The master unit's DIP switch address is set to 1, responsible for communicating with the host computer and managing data exchange with all slave units. The slave units have DIP switch addresses sequentially designated as 2, 3, ..., N. Each slave unit manages a group of batteries, responsible for collecting battery parameters such as voltage, current, and temperature, and executing control commands issued by the master unit. The host computer monitoring system supports multiple communication protocols, such as the RS232-based MS protocol, the RS485-based Modbus protocol, the SNMP protocol, and the TCP Modbus protocol, for remote monitoring and setting of BMS parameters. The parallel communication network uses a CAN bus or RS485 bus to connect the master unit and all slave units for transmitting real-time data, alarm information, and control commands. The master unit communicates with each slave unit via a second communication bus, which can be either a CAN bus or an RS485 bus. The host computer communicates with the host computer through a first communication interface, which can be an Ethernet interface, an RS232 interface, or an RS485 interface, and carries a first communication protocol such as SNMP protocol, Modbus protocol, or serial MS protocol.

[0024] Figure 1 This invention provides an architecture diagram of a battery management system that supports multi-protocol parallel communication. like Figure 1 As shown, the host computer communicates bidirectionally with the main unit via the first communication protocol (SNMP protocol in this embodiment), and the main unit communicates bidirectionally with slave 1 and slave 2 via the second communication bus (CAN bus in this embodiment). Each slave unit independently connects to and manages a group of batteries, realizing distributed battery parameter acquisition and control.

[0025] Furthermore, the host's multi-protocol conversion and forwarding mechanism is as follows: The host internally sets up a protocol conversion scheduling module, which has three functions: protocol identification and parsing, protocol encapsulation and forwarding, and response reception and transmission. Regarding protocol identification and parsing, the host listens to the host computer interface (e.g., Ethernet, RS232, RS485), identifies the access protocol type (SNMP, Modbus, MS protocol, etc.), parses the request messages sent by the host computer, and extracts key data fields (such as slave address, parameter address, setting values, etc.). Regarding protocol encapsulation and forwarding, the host re-encapsulates the extracted data fields into data frames recognizable by the slave according to the parallel communication protocol, and sends the encapsulated command frames to the target slave via CAN or 485 bus. Regarding response reception and transmission, the host receives the response data frames returned by the slave, restores them to the protocol format used by the host computer, and transmits the response back to the host computer through the corresponding host computer interface.

[0026] The following uses the SNMP protocol as an example to illustrate the complete communication process of transparent protocol forwarding. The host computer sends a SetRequest message to the master computer via the SNMP protocol to set the upper charging voltage limit of a battery connected to a slave device. The master computer identifies the first communication protocol used by the host computer as SNMP, receives and parses the request message, extracting the target slave device identifier and operation information containing the characteristics of the first communication protocol. This operation information includes the target OID field of the SNMP protocol (e.g., 1.3.6.1.4.1.xxxx.1.2.1) and the setting value (e.g., 4.2V). The master computer encapsulates this information into a CAN data frame, where the CAN identifier contains the slave device address, and the data segment contains the OID and the value. The master computer then sends the downlink data frame to the corresponding target slave device via the CAN bus. The target slave device receives the CAN data frame, parses the target OID field and the setting value from the data frame, and performs local parameter setting operations on the connected battery according to the parsed operation information. After the slave device performs the operation, the master computer receives the response frame returned by the slave device, extracts the execution result from the response frame, reassembles the execution result into a GetResponse message according to the SNMP protocol, and returns it to the host computer. Through the above process, the slave device can directly respond to the instructions issued by the host computer via the SNMP protocol without the host needing to completely parse and reassemble the protocol content. This reduces the application layer processing steps of the protocol data packets by the host and improves the real-time performance of the instruction response.

[0027] When the host computer sends a request, the system first determines whether the request target is the host itself. If it is a read / write request for the host's own parameters, the host responds directly; if it is a read / write request for the slave's parameters, the host performs protocol conversion and forwarding, the slave processes the request, and then the host sends the response back to the host computer.

[0028] The following uses the SNMP protocol as an example to illustrate the complete communication process of transparent protocol forwarding. The host computer sends a SetRequest message to the master computer via the SNMP protocol to set the upper limit charging voltage of the battery connected to a certain slave device. The master computer recognizes that the first communication protocol used by the host computer is the SNMP protocol, receives and parses the request message, and extracts the target slave device identifier and operation information containing the characteristics of the first communication protocol. The operation information includes the target OID field of the SNMP protocol (e.g., 1.3.6.1.4.1.xxxx.1.2.1) and the setting value (e.g., 4.2V). The host encapsulates this information into a CAN data frame, where the CAN identifier contains the slave address and the data segment contains the OID and value. The host then sends the downlink data frame to the corresponding target slave via the CAN bus. The target slave receives the CAN data frame, parses the target OID field and setting value from it, and performs local parameter setting operations on the connected battery based on the parsed operation information. After performing the operation, the slave generates response data containing the execution result, encapsulates the response data into a response frame conforming to the CAN bus protocol, and returns it to the host via the CAN bus. The host receives the response frame returned by the slave, extracts the execution result from it, reassembles the result into a GetResponse response message according to the SNMP protocol, and returns it to the host computer.

[0029] Furthermore, the slave device is also configured to: after performing local operations, generate response data containing the execution results, encapsulate the response data into a response frame conforming to the second communication protocol, and return the response frame to the master device through the second communication bus; The host is also configured to: receive response frames returned by the slave, extract execution results from the response frames, encapsulate the execution results into a response message according to the first communication protocol, and return the response message to the host computer through the first communication interface, so that the slave can directly respond to the instructions issued by the host computer according to the first communication protocol.

[0030] In this embodiment, in the example of the SNMP setting operation described above, after the slave device performs the local parameter setting operation, it generates response data containing the execution result (e.g., "setting successful" or an error code), and encapsulates the response data into a response frame conforming to the CAN bus protocol, returning it to the host device via the CAN bus. The host device receives the response frame, extracts the execution result from it, and encapsulates the execution result into a GetResponse response message according to the SNMP protocol, returning it to the host computer via the Ethernet interface, thus completing a complete command response loop.

[0031] Furthermore, both the master and slave devices are equipped with address dialing codes. The master device determines itself as the master by reading its own address dialing code value as a preset master address value, and loads the protocol conversion scheduling module to perform protocol conversion and forwarding functions between the first communication protocol and the second communication protocol. The slave device determines itself as the slave by reading its own address dialing code value as a non-master address value, and loads the protocol adaptation execution module to perform parsing and local operation functions on downlink data frames.

[0032] In this embodiment, both the master and slave devices in the system are equipped with hardware address DIP switches. During power-on initialization, the master device reads its own address DIP switch value. When the DIP switch value is the preset master address value 1, it determines itself as the master and loads the protocol conversion scheduling module to perform protocol conversion and forwarding functions between the first and second communication protocols. When the slave device reads its own address DIP switch value as a non-master address value (e.g., 2, 3, ..., N), it determines itself as the slave device and loads the protocol adaptation execution module to perform parsing and local operation functions on downlink data frames. By using address DIP switches, the master / slave roles are automatically determined and functional modules are dynamically loaded. System networking can be completed without manual configuration, significantly simplifying the deployment process and improving the system's plug-and-play capability.

[0033] Furthermore, the host is also configured to: during the power-on initialization phase, scan the address DIP switches of each slave device, automatically determine the number of slave devices and communication addresses based on the scanned DIP switch values, and dynamically establish a data polling list based on the number of slave devices and communication addresses; the host divides the data polling period T into N time slots according to the number of slave devices N, with each time slot corresponding to one slave device, and sends data request frames to each slave device in ascending order of address DIP switches.

[0034] In this embodiment, during the power-on initialization phase, the host scans the address DIP switches of each slave device via the second communication bus. Based on the scanned DIP switch values, it automatically determines the number of slave devices N and their communication addresses. For example, if the scanned DIP switch values ​​are 2, 3, 4, and 5, then the number of slave devices N=4, and the communication addresses are 2, 3, 4, and 5, respectively. The host dynamically establishes a data polling list based on the number of slave devices and their communication addresses, dividing the data polling period T into four time slots, each corresponding to one slave device. Data request frames are sent to each slave device sequentially in ascending order of address DIP switches. When a slave device goes offline, the host automatically skips the corresponding time slot, dynamically shortening the polling period. This mechanism allows the host to adapt to changes in the parallel device scale without redesigning the communication scheduling logic, thereby improving system scalability.

[0035] Furthermore, the host computer is equipped with a protocol conversion scheduling module and a global data buffer. The protocol conversion and scheduling module is used to identify, parse, encapsulate, and forward protocol data between the first and second communication protocols. The host is also configured to: during idle periods when there is no instruction interaction with the host computer, periodically poll the real-time data of each slave through the second communication bus and store the acquired real-time data in the global data buffer; when it receives a query request for real-time data from the host computer, it directly reads the real-time data from the global data buffer and encapsulates the real-time data into response data and sends it to the host computer.

[0036] In this embodiment, the host computer internally includes a protocol conversion scheduling module and a global data buffer. The protocol conversion scheduling module is responsible for identifying, parsing, encapsulating, and forwarding protocol data between the first and second communication protocols. When there are no instructions from the host computer, the host continuously requests real-time data (voltage, current, temperature, alarm status, etc.) from each slave device via CAN or RS-485 and maintains the global data buffer. When a query request for real-time data is received from the host computer, the host directly reads the data from the global data buffer, encapsulates it into response data, and sends it to the host computer, without the need for real-time polling. This global data buffer mechanism separates data acquisition from query response, thereby improving response speed and reducing bus load.

[0037] Furthermore, the operation information extracted by the host from the first protocol request message includes the target OID field or function code of the first communication protocol; the slave device is equipped with a protocol adaptation execution module, which is used to parse the target OID field or function code from the received downlink data frame, and determine the corresponding operation type and operation parameters based on the parsed target OID field or function code.

[0038] In this embodiment, the slave device internally includes a protocol adaptation and execution module. This module has two functions: receiving and parsing host commands, and local execution and response. Regarding receiving and parsing host commands, the slave device receives data frames forwarded by the host from the CAN or 485 bus, and parses the original protocol type (such as SNMP OID, Modbus function code) and parameter content according to the frame format. Regarding local execution and response, the slave device performs corresponding operations (such as reading battery data, modifying parameters, and clearing alarms) based on the parsing results, encapsulates the execution results into a response frame according to the same protocol format, and sends it back to the host via the CAN or 485 bus. In the SNMP protocol example, the operation information extracted by the host from the SetRequest message includes the target OID field (1.3.6.1.4.1.xxxx.1.2.1) and the setting value (4.2V). The protocol adaptation and execution module internally parses the target OID field from the received CAN data frame, determines the corresponding operation type as "set charging upper limit voltage" and the operation parameter as "4.2V" based on the OID field, and then performs the corresponding local parameter setting operation. When using the Modbus protocol, the master extracts the function code (such as 06 to write a single register) and the register address, and the slave's protocol adaptation execution module determines the operation type and operation parameters accordingly.

[0039] Furthermore, when the host sends a downlink data frame, it encapsulates the target slave identifier in the frame header or address field of the downlink data frame and sends the downlink data frame to the target slave in a unicast manner. After receiving the downlink data frame, the slave compares the target slave identifier in the downlink data frame with its own address dialing to determine whether it is the target slave. If the result is yes, it performs parsing and response operations on the downlink data frame. If the result is no, it discards the downlink data frame.

[0040] In this embodiment, when the host encapsulates the CAN data frame, it encapsulates the target slave identifier (such as DIP address 3) in the identifier field of the CAN frame and sends it to the CAN bus via unicast. All slaves receive the data frame, but only the slave with address DIP address 3 determines itself as the target slave by comparing the target slave identifier in the frame with its own address DIP address, and then performs parsing and response operations; other slaves that do not match the target slave identifier discard the data frame, thereby avoiding false responses from non-target slaves.

[0041] Furthermore, the system includes multiple hosts, each of which connects to and manages at least one slave device. Each host communicates independently with the host computer, forming a multi-host parallel architecture. The host computer interacts with each host through a unified first communication protocol, and each host interacts with its connected slave device through its own second communication bus.

[0042] In this embodiment, in a large-scale energy storage power station scenario, the system can include multiple hosts, each host connecting to and managing at least one slave (e.g., host A manages slaves A1 to A4, and host B manages slaves B1 to B6). Each host communicates independently with the host computer, forming a multi-host parallel architecture. The host computer interacts with each host via a unified SNMP protocol, and each host interacts with its connected slaves via its respective CAN bus. When the system needs to be expanded, only hosts and corresponding slaves need to be added, while the communication protocol on the host computer side remains unchanged, thereby improving the system's scalability.

[0043] Furthermore, the second communication bus between the master and each slave device adopts the CAN bus, and there is also a redundant backup second communication bus connected between the master and each slave device. When the master bus fails, the system automatically switches the communication to the backup bus to continue communication.

[0044] In this embodiment, two CAN buses connect the master and each slave device: one is the primary bus, and the other is a backup bus. During normal system operation, all data communication occurs through the primary bus. The master periodically checks the communication status of the primary bus. When a disconnection or short circuit fault is detected on the primary bus, the system automatically switches communication to the backup bus, and all data interaction continues through the backup bus. This redundant bus design improves the reliability of system communication.

[0045] Furthermore, after parsing the first protocol request message, the host establishes and maintains a protocol mapping table, which records the correspondence between the characteristic fields of the first communication protocol and the frame identifiers of the second communication protocol. After receiving the response frame returned by the slave, the host restores the response frame into a response message conforming to the first communication protocol according to the correspondence recorded in the protocol mapping table.

[0046] In this embodiment, after parsing the SNMPSetRequest message, the host establishes and maintains a protocol mapping table. This table records the correspondence between SNMP OIDs and CANIDs (e.g., OID 1.3.6.1.4.1.xxxx.1.2.1 corresponds to CANID 0x301). When the host receives a response frame (CANID 0x301) from the slave, it restores the response frame to an SNMPGetResponse message based on the correspondence recorded in the mapping table. The OID field is filled with 1.3.6.1.4.1.xxxx.1.2.1, and the numeric field is filled with the execution result. This protocol mapping table mechanism enables the host to efficiently complete bidirectional protocol conversion without re-parsing and matching protocol fields each time, thereby improving protocol conversion efficiency and system real-time performance.

[0047] Furthermore, in this embodiment, the system described in this invention is applied to a pure electric commercial vehicle; the vehicle is equipped with a distributed battery management system consisting of one host computer, one master computer, and four slave computers.

[0048] In this embodiment, the host computer is specifically the vehicle control unit (VCU) of the pure electric commercial vehicle. The VCU is the core control unit of the vehicle's electrical system, responsible for the energy distribution, drive control and status monitoring of the whole vehicle. In the distributed BMS architecture described in this invention, the VCU communicates with the host through the CAN bus, and issues instructions and receives data using the CAN application layer protocol customized by the vehicle manufacturer. The VCU does not communicate directly with the slave devices of each battery box, but regards the host as a unified agent for the entire battery system. The host completes the protocol conversion and scheduling of the subordinate slave devices.

[0049] In this system, the master and slave are two independent circuit board hardware devices with different physical forms and different functions. They automatically identify their master and slave roles through address DIP switches, without the need for manual software configuration.

[0050] The host unit is a central control board without any battery sampling interface, installed in the high-voltage control box of the vehicle chassis. The board has an address DIP switch, factory-set to a fixed value of 1. The host integrates two CAN interfaces in the uplink direction, one of which connects to the vehicle controller (VCU) and runs the vehicle manufacturer's custom CAN application layer protocol (the first communication protocol). In the downlink direction, it integrates two CAN interfaces, connected in parallel with all slave units in a master-slave redundancy configuration, running the BMS's custom CAN application layer protocol (the second communication protocol). The host board has no voltage sampling terminals, no temperature sensor interfaces, no equalization circuits, and is not directly connected to any battery cells. The host's core tasks are only two: protocol conversion and forwarding, and global data polling and buffering. After power-on, the host reads its own DIP switch as 1, determines itself as the host, automatically loads the protocol conversion scheduling module, establishes a protocol mapping table and a global data buffer, and enters host operating mode.

[0051] The slave unit is an execution board with a complete battery sampling and control interface. Each slave unit is independently installed inside a standard battery box and is directly connected to all the series-connected battery cells in the battery box via a wiring harness. The slave unit board also has an address DIP switch, with DIP values ​​of 2, 3, 4, and 5 for the four slave units, respectively. Specifically, the slave unit integrates multiple high-precision voltage sampling terminals, multiple temperature sensor interfaces, a passive equalization resistor network, and a charge / discharge MOSFET control interface, but only integrates one CAN interface, connected to the internal CAN bus managed by the host, and does not communicate directly with the VCU. The slave unit also has two core tasks: first, to continuously collect the voltage, temperature, and total current of each cell in the battery box; second, to receive downlink data frames sent by the host, parse the operation information originating from the first communication protocol characteristics, and directly execute local operations. After the slave unit is powered on, if its own DIP switch is not 1, it determines that it is a slave unit, automatically loads the protocol adaptation execution module, and enters the slave unit working mode.

[0052] Furthermore, the master unit is the only communication bridge between the slave unit and the entire vehicle. However, the slave unit does not rely on the master unit for semantic translation at the protocol understanding level. The protocol adaptation and execution module inside the slave unit enables it to directly digest the characteristic information of the first communication protocol.

[0053] Furthermore, although the physical layer of the first communication protocol and the second communication protocol is CAN, their application layer protocol specifications are completely different. The frame format, identifier definition, and data field encoding rules belong to two independent protocol systems. Under the above hardware architecture, the vehicle has a total of 4 standard battery boxes, each of which is equipped with 1 slave unit. The slave unit address dials are 2, 3, 4, and 5 respectively, and the master unit address dial is 1. The VCU communicates with the master unit through the CAN bus using the vehicle manufacturer's custom CAN protocol (first communication protocol). The master unit and each slave unit are networked through the internal CAN bus (second communication protocol).

[0054] The following describes the implementation of the battery management system supporting multi-protocol parallel communication of the present invention through three specific scenarios: Scenario 1: The VCU queries the state of charge (SOC) of a battery pack in real time while the vehicle is in motion. During normal vehicle operation, the VCU needs to monitor the SOC of each battery pack in real time to make energy allocation decisions. The VCU sends a first communication protocol request message to the host. The CAN identifier of this message is defined as 0x100 according to the vehicle protocol specification. The data field contains function code 0x03, target battery pack logical number 3, and parameter type code 0x01.

[0055] After the host receives the request message through the first communication interface, the internal protocol conversion and scheduling module first identifies the first communication protocol used by the message as the vehicle's custom CAN protocol; the host parses the message, extracts the target slave identifier as 3, and operation information containing the characteristics of the first communication protocol; the operation information specifically includes: function code 0x03 and parameter type code 0x01.

[0056] The host queries the internally maintained protocol mapping table, which was established during system initialization and records the correspondence between the characteristic fields of the first communication protocol and the frame identifiers of the second communication protocol. According to the mapping table, the second communication protocol address corresponding to the target slave 3 is 0x03, and the operation type "read request and parameter type 0x01" corresponds to the function identifier 0x50 in the second communication protocol. Based on the above mapping relationship, the host re-encapsulates the operation information into a downlink CAN data frame according to the second communication protocol, filling the identifier field with the target slave address 0x03 and the function identifier 0x50, and filling the data field with the parameter type code 0x01. This downlink data frame is sent to the target slave 3 via the internal CAN bus in unicast mode.

[0057] After receiving the downlink data frame, slave device 3 compares the target slave address 0x03 in the frame with its own address dial code value 3, determines that it is the target slave, and enters the processing flow. The protocol adaptation execution module inside the slave device parses the function identifier 0x50 from the data frame and determines that the function identifier corresponds to "reading the parameter indicated by the parameter type code 0x01" according to the preset mapping relationship. It should be noted that the slave device can directly understand the complete operational meaning of the combination of function identifier 0x50 and parameter type code 0x01, that is, "reading the SOC value of this battery box". This is the core capability that distinguishes this invention from the prior art: the slave device directly digests the operational information derived from the characteristics of the first communication protocol without the need for intermediate semantic translation by the host.

[0058] The slave device then performs local operations, collects the current SOC data of the battery box (assuming it is 78%), generates response data containing the execution result, encapsulates the response data into a response frame conforming to the second communication protocol, and returns it to the master device via the internal CAN bus.

[0059] After receiving the response frame returned by slave device 3, the master device, based on the correspondence recorded in the aforementioned protocol mapping table, restores the execution result (SOC=78%) in the response frame into a response message conforming to the first communication protocol, and returns it to the VCU via the CAN interface. After receiving the message, the VCU learns that the current SOC of battery box 3 is 78%, completing a complete command response loop.

[0060] During this process, due to the host's use of a global data buffer and periodic polling mechanism, during idle periods when the VCU does not initiate a query request, the host periodically polls the real-time data of each slave device via the internal CAN bus and stores data such as the SOC in the host's internal global data buffer. When the VCU's query request arrives, if the corresponding SOC data in the buffer is still valid, the host can directly read the data from the buffer and encapsulate the response, further shortening the response latency. This buffering mechanism, working in conjunction with the protocol conversion mechanism, gives this system a significant advantage in the high real-time scenario of vehicle operation.

[0061] Scenario 2: VCU remotely adjusts the charging cutoff voltage of a battery box; During the vehicle charging preparation phase, the VCU, based on the battery health status assessment results, decides to adjust the charging cutoff voltage of battery pack #2 from 4.2V to 4.15V. The VCU sends a first communication protocol write request message to the host, with a CAN identifier of 0x200. The data field contains function code 0x06, target battery pack logical number 2, parameter type code 0x02 (representing the charging cutoff voltage), and parameter value 4.15.

[0062] After receiving the message, the host parses and extracts the target slave identifier 2, as well as operation information containing the characteristics of the first communication protocol: function code 0x06, parameter type code 0x02, and parameter value 4.15. The protocol mapping table lookup results show that target slave 2 corresponds to the second communication protocol address 0x02, and the combination of the write operation and parameter type code 0x02 corresponds to the second communication protocol function identifier 0x51. The host encapsulates the above operation information into a downlink CAN data frame according to the second communication protocol and sends it to slave 2 via unicast.

[0063] After receiving the data, slave device 2 parses the function identifier 0x51 and parameter type code 0x02, directly interpreting the operation as "write charging cut-off voltage," with a parameter value of 4.15V. The slave device then calls the local control interface to update the charging cut-off voltage register of the battery box's BMS protection board to 4.15V. Upon completion, the slave device generates response data (operation result = success), encapsulates it into a response frame, and returns it to the host. The host, based on the mapping table, reconstructs the response into a first communication protocol message and sends it back to the VCU, completing the closed loop.

[0064] Scenario 3: Adaptive communication scheduling when the number of slave devices changes dynamically; Suppose that due to vehicle maintenance, battery box #4 is temporarily removed, reducing the system from 4 slave devices to 3. During the power-on initialization phase, the master unit scans the address DIP switches of each slave device. It only detects DIP switch values ​​2, 3, and 5, automatically determining the current number of slave devices N=3, with communication addresses 2, 3, and 5 respectively. Based on this number of slave devices, the master unit dynamically establishes a data polling list, evenly dividing the data polling period T into 3 time slots. Data request frames are sent sequentially to slave devices 2, 3, and 5 in ascending order of address DIP switch values. The time slot originally corresponding to slave device 4 is automatically removed, shortening the polling period and thus improving the data refresh rate for online slave devices.

[0065] This embodiment applies the present invention to a containerized energy storage power station. The power station consists of one host computer, one master computer, and three slave computers.

[0066] The host computer is the power plant's energy management system (EMS), deployed on a server in the control room. It communicates with the host via Ethernet using the SNMP protocol and is responsible for monitoring and scheduling all batteries in the plant. The host is a central control board without a battery sampling interface, installed in the high-voltage control cabinet, with address DIP code 1. The board integrates an Ethernet interface for connecting to the EMS and two CAN interfaces for connecting to the slave devices. The slave devices are execution boards with complete sampling and control interfaces, with address DIP codes 2, 3, and 4 respectively. Each slave is installed in the high-voltage box of a battery cluster and is directly connected to all individual battery cells in its cluster via wiring harnesses.

[0067] Scenario: EMS remotely adjusts the charging overcurrent protection delay. Maintenance personnel adjust the charging overcurrent protection delay of battery cluster 2 from 100ms to 50ms via the EMS interface, corresponding to SNMP OID 1.3.6.1.4.1.xxxx.2.1.5. The EMS sends a SetRequest message to the host. Upon receiving the message, the host identifies the first communication protocol as SNMP, extracts the target slave identifier 3 and operation information containing the first protocol characteristics, including the OID and the setting value 50. The host does not need to understand the physical meaning of this OID. The host queries the protocol mapping table, assigns the OID to the second communication protocol function identifier 0x60, encapsulates it into a downlink CAN frame, and unicasts it to slave 3. Upon receiving the message, slave 3's protocol adaptation execution module directly parses the SNMP OID from the CAN frame, interpreting its meaning as "modify the charging overcurrent protection delay to 50ms," and then calls the local interface to update the protection board register. After successful execution, the slave encapsulates the result into a CAN response frame and returns it to the host. The host restores the response as an SNMP GetResponse message based on the mapping table and sends it back to EMS. The interface displays that the setup was successful.

[0068] In this process, the slave device directly digests and executes the SNMP protocol feature information, while the master device only extracts protocol features and encapsulates the format, without participating in application layer semantic translation, thus realizing cross-protocol transparent communication and low-latency data interaction.

[0069] In another embodiment, the present invention is applied to a containerized energy storage power station, which consists of one host computer, one master computer and three slave computers.

[0070] The host computer is the power plant's energy management system (EMS), deployed on the server in the control room. It communicates with the host via Ethernet using the SNMP protocol and is responsible for monitoring and scheduling the batteries throughout the plant. The host is a central control board without a battery sampling interface, installed in the high-voltage control cabinet. Its address DIP switch is 1. The board integrates an Ethernet interface to connect to the EMS and two CAN interfaces to connect to the slave devices. The slave devices are execution boards with complete sampling and control interfaces. Their address DIP switches are 2, 3, and 4, respectively. Each slave device is installed in the high-voltage box of a battery cluster and is directly connected to all the individual battery cells in the cluster via wiring harnesses.

[0071] Specifically, when remotely adjusting the charging overcurrent protection delay via EMS, maintenance personnel adjust the charging overcurrent protection delay of battery cluster 2 from 100ms to 50ms through the EMS interface. The EMS sends a SetRequest message to the host. Upon receiving the message, the host identifies the first communication protocol as SNMP, extracts the target slave identifier 3 and operation information containing the characteristics of the first protocol (OID and setting value 50). The host does not need to understand the physical meaning of this OID. The host queries the protocol mapping table, assigns the OID to the second communication protocol function identifier 0x60, encapsulates it into a downlink CAN frame, and unicasts it to slave 3. Upon receiving the message, slave 3's protocol adaptation execution module directly parses the SNMP OID from the CAN frame, interpreting its meaning as "modify charging overcurrent protection delay to 50ms," and then calls the local interface to update the protection board register. After successful execution, the slave encapsulates the result into a CAN response frame and returns it to the host. The host, based on the mapping table, restores the response to an SNMP GetResponse message and sends it back to the EMS, and the interface displays a successful setting.

[0072] In this process, the slave device can directly digest and execute the SNMP protocol feature information, while the host device only performs protocol feature extraction and format encapsulation without participating in application layer semantic translation, thus achieving cross-protocol transparent communication and low-latency data interaction.

[0073] The above are only some embodiments of the present invention and do not limit the patent scope of the present invention. All equivalent structural transformations made under the technical concept of the present invention using the contents of the present invention specification and drawings, or direct / indirect applications in other related technical fields, are included within the patent protection scope of the present invention.

Claims

1. A battery management system supporting multi-protocol parallel communication, comprising a host computer, a master computer, and at least one slave computer, each slave computer being connected to a group of batteries for collecting battery parameters of the connected batteries, the master computer communicating with each slave computer via a second communication bus, and the master computer communicating with the host computer via a first communication interface, characterized in that: The host is configured to: identify the first communication protocol used by the host computer; receive a first protocol request message from the host computer; and parse the first protocol request message to extract the target slave identifier and operation information containing the characteristics of the first communication protocol. The operation information is re-encapsulated into a downlink data frame according to the second communication protocol used for communicating with the slave device, and the downlink data frame is sent to the target slave device; The slave device is configured to: receive the downlink data frame and parse operation information corresponding to the first communication protocol feature from the downlink data frame; Execute local operations based on the parsed operation information; The host is further configured to: receive a response frame returned by the slave device, extract the execution result from the response frame, encapsulate the execution result into a response message according to the first communication protocol, and return the response message to the host computer, so that the slave device can directly respond to the instructions issued by the host computer according to the first communication protocol.

2. The battery management system supporting multi-protocol parallel communication according to claim 1, characterized in that, The slave device is further configured to: after performing the local operation, generate response data containing the execution result, encapsulate the response data into a response frame conforming to the second communication protocol, and return the response frame to the host device through the second communication bus; The host is further configured to: receive the response frame returned by the slave, extract the execution result from the response frame, encapsulate the execution result into a response message according to the first communication protocol, and return the response message to the host computer through the first communication interface, so that the slave can directly respond to the instructions issued by the host computer according to the first communication protocol.

3. The battery management system supporting multi-protocol parallel communication according to claim 1, characterized in that, The host and the slave are each equipped with an address dial code. The host determines itself as the host by reading its own address dial code value as a preset host address value, and performs protocol conversion and forwarding functions between the first communication protocol and the second communication protocol. The slave determines itself as the slave by reading its own address dial code value as a value other than the host address value, and performs parsing and local operation functions on the downlink data frame.

4. The battery management system supporting multi-protocol parallel communication according to claim 1, characterized in that, The host is also configured to: during the power-on initialization phase, scan the address DIP switches of each slave device, automatically determine the number of slave devices and communication addresses based on the scanned DIP switch values, and dynamically establish a data polling list based on the number of slave devices and the communication addresses; the host divides the data polling period T into N time slots according to the number of slave devices N, with each time slot corresponding to one slave device, and sends data request frames to each slave device in ascending order of address DIP switches.

5. The battery management system supporting multi-protocol parallel communication according to claim 1, characterized in that, The host is equipped with a protocol conversion scheduling module and a global data buffer. The protocol conversion scheduling module is used to identify, parse, encapsulate, and forward protocol data between the first communication protocol and the second communication protocol; The host is also configured to: during idle periods when there is no instruction interaction with the host computer, periodically poll the real-time data of each slave device through the second communication bus, and store the acquired real-time data in the global data buffer; when receiving a query request for the real-time data from the host computer, directly read the real-time data from the global data buffer, and encapsulate the real-time data into response data and send it to the host computer.

6. The battery management system supporting multi-protocol parallel communication according to claim 1, characterized in that, The operation information extracted by the host from the first protocol request message includes the target OID field or function code of the first communication protocol; the slave device is equipped with a protocol adaptation execution module, which is used to parse the target OID field or function code from the received downlink data frame, and determine the corresponding operation type and operation parameters based on the parsed target OID field or function code.

7. The battery management system supporting multi-protocol parallel communication according to claim 1, characterized in that, When the host sends the downlink data frame, it encapsulates the target slave identifier in the frame header or address field of the downlink data frame and sends the downlink data frame to the target slave in a unicast manner. After receiving the downlink data frame, the slave device compares the target slave device identifier in the downlink data frame with its own address dialing code to determine whether it is the target slave device. If the determination result is yes, it performs parsing and response operations on the downlink data frame; if the determination result is no, it discards the downlink data frame.

8. The battery management system supporting multi-protocol parallel communication according to claim 1, characterized in that, The system includes multiple hosts, each host managing a group of slave devices and communicating independently with the host computer; each host connects to and manages at least one slave device, and each host communicates independently with the host computer, forming a multi-host parallel architecture; the host computer interacts with each host through a unified first communication protocol, and each host interacts with its connected slave devices through its own second communication bus.

9. The battery management system supporting multi-protocol parallel communication according to claim 1, characterized in that, The second communication bus between the master and each slave device adopts a CAN bus, and the master and each slave device are also connected to a redundant backup second communication bus. When the master bus fails, the system automatically switches the communication to the backup bus to continue communication.

10. The battery management system supporting multi-protocol parallel communication according to claim 1, characterized in that, After parsing the first protocol request message, the host establishes and maintains a protocol mapping table, which records the correspondence between the feature fields of the first communication protocol and the frame identifier of the second communication protocol. After receiving the response frame returned by the slave device, the host restores the response frame into a response message conforming to the first communication protocol according to the correspondence recorded in the protocol mapping table.

Images