FPGA-based testing apparatus and method
By using FPGA hardware-in-the-loop simulation technology, the problems of high cost, long cycle and security risks of traditional BMS software verification solutions are solved, realizing efficient and flexible battery cluster management unit testing, and improving test coverage and security.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- JIANGSU TIANHE ENERGY STORAGE CO LTD
- Filing Date
- 2026-06-12
- Publication Date
- 2026-07-14
AI Technical Summary
Traditional battery management system (BMS) software verification solutions rely on real battery cluster-level testing environments, resulting in long testing cycles, high costs, insufficient scenario coverage and verification reliability, as well as safety risks and limited flexibility.
An FPGA-based testing device is used to generate cell simulation data through a data generation unit. The behavior of the battery cluster management unit is simulated using the AFE simulation unit within the FPGA to achieve hardware-in-the-loop simulation, including logic processing and communication interfaces, simulating various operating conditions and fault scenarios of the battery cluster.
Verification can be completed without a real battery cluster-level testing environment, significantly reducing testing costs and improving verification efficiency. It supports a variety of AFE chips, achieves microsecond-level deterministic response, and improves test coverage and security.
Smart Images

Figure CN122386006A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of battery management testing technology, and more specifically, to an FPGA-based testing device and method. Background Technology
[0002] The battery management system (BMS) plays a core monitoring role in energy storage systems. By collecting key parameters such as battery pack voltage, current, and temperature in real time and executing dynamic threshold control strategies, it directly affects the efficiency and safety of the battery pack.
[0003] Current energy storage BMS software logic verification solutions mainly involve building a real cluster-level test bench and modifying the software's trigger thresholds to verify the protection logic; traditional BMS software verification processes have significant limitations. Reliance on physical test benches and lengthy testing cycles: It requires building a real battery cluster-level test environment and triggering alarms by charging and discharging or modifying BCU-level thresholds, resulting in long verification cycles and high costs. Insufficient scenario coverage and verification reliability: It is difficult to simulate extreme voltage / temperature combinations or fault conditions, and the test coverage is limited.
[0004] Safety risks and flexibility challenges: When validating procedures in real-world environments, not only is operational flexibility limited, but the safety risks associated with battery pack operation also increase the difficulty of managing the experimental environment. Furthermore, the near-immutability or difficulty in manufacturing variations of cell parameters restricts the possibility of technological improvements and innovations. Summary of the Invention
[0005] This application proposes an FPGA-based testing device and method to address the significant limitations of traditional BMS software verification processes.
[0006] This application proposes an FPGA-based test apparatus for testing a battery cluster management unit, comprising: The data generation unit generates and distributes simulated cell data. An FPGA is provided, which contains at least one AFE simulation unit obtained through different configuration files. The FPGA receives the cell simulation data, responds to the instruction request of the battery cluster management unit, starts the corresponding AFE simulation unit according to the instruction type, processes the cell simulation data according to preset rules, and generates corresponding response data within a preset delay period. A communication interface is provided to connect the battery cluster management unit and the FPGA to send the response data generated by the FPGA to the battery cluster management unit.
[0007] In some embodiments, the FPGA includes: UART receives cell simulation data sent by the data generation unit; An AFE simulation unit, the AFE simulation unit comprising: The block memory acquires the simulated data of the battery cell and stores it according to a preset register array; An SPI slave unit is connected to the communication interface to receive instruction requests from the battery cluster management unit; In addition, a logic processing unit is connected to the block memory and the SPI slave unit respectively. It obtains the instruction request through the SPI slave unit, parses the instruction, reads the cell simulation data and generates response data according to the corresponding preset rules, and returns the response data to the battery cluster management unit through the SPI slave unit.
[0008] In some embodiments, the logic processing unit includes: The command parsing unit parses the instructions sent by the battery cluster management unit through the SPI slave unit and identifies the instruction type and the target cell address. The data reading unit reads the simulated cell data from the corresponding address in the block memory according to the target cell address; The response generation unit packages the read cell simulation data into response data according to the communication protocol of the target AFE chip; The timing control unit controls the timing of command parsing, data reading, and response generation to ensure compliance with the timing requirements of the target AFE chip.
[0009] In some embodiments, the FPGA further includes: A clock management unit is used to generate at least one clock. Each AFE analog unit responds to the instructions of the battery cluster management unit under the drive of the corresponding clock and generates response data within the preset delay period.
[0010] In some embodiments, the FPGA includes: Multiple AFE simulation units, each of which is communicatively connected to a corresponding battery cluster management unit; The plurality of AFE simulation units are configured to operate in a switchable topology, which includes a parallel topology, a serial topology, or a cascaded topology. In a parallel topology, the multiple AFE simulation units communicate synchronously and independently with their corresponding battery cluster management units; In a serial topology, the multiple AFE simulation units communicate with their corresponding battery cluster management units in a preset timing sequence; or In a cascaded topology, the multiple AFE simulation units are connected in series and then communicate with the battery cluster management unit.
[0011] In some embodiments, the plurality of AFE simulation units may be configured to share the same clock domain or use their own independent clock domains to accommodate different testing requirements.
[0012] In some embodiments, the data generation unit further includes: The test sequence generation module is used to generate multi-level cell simulation data according to the preset protection thresholds of the battery cluster management unit, and send it to the FPGA in sequence to trigger different levels of protection responses of the battery cluster management unit in turn, record the response actions of the battery cluster management unit, and generate a test report.
[0013] In some embodiments, the test sequence generation module is further configured to acquire the output signal of the battery cluster management unit, record different levels of protection response actions that cross each preset protection threshold, and generate an automated test report.
[0014] In some embodiments, the preset protection threshold includes at least: Any one or more of the following: upper voltage threshold, lower voltage threshold, upper temperature threshold, and lower temperature threshold.
[0015] This application also provides an FPGA-based testing method for testing a battery cluster management unit, including: Generate and distribute cell simulation data; By using different configuration files, at least one AFE simulation unit is obtained within the FPGA to receive and store the cell simulation data. In response to the instruction request from the battery cluster management unit, the corresponding AFE simulation unit is started according to the instruction type, the cell simulation data is processed according to preset rules, and corresponding response data is generated within a preset delay period. The response data is sent to the corresponding battery cluster management unit.
[0016] With the above technical solution, this application simulates the battery management unit (BMU) and data generation unit through FPGA and communication interface, generates and sends out simulated cell data, without the need for real cells, avoiding the disadvantages of high cost, long cycle and high risk of physical test bench; FPGA hardware logic realizes microsecond-level deterministic response, realistically simulates AFE timing; reconfigurable to support multiple AFE chips, improves test efficiency. Attached Figure Description
[0017] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.
[0018] To more clearly illustrate the technical solutions in the embodiments of this application 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.
[0019] Figure 1 This is a schematic diagram of the structure of an FPGA-based test device according to an embodiment of this application; Figure 2 This is a schematic flowchart of a test apparatus method based on an embodiment of this application; Figure 3 This is a schematic diagram of the FPGA-based test method according to Embodiment 1 of this application. Detailed Implementation
[0020] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort should fall within the scope of protection of the present application.
[0021] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.
[0022] This application provides a test device based on FPGA, see attached document. Figure 1 , Figure 1 This is a schematic diagram of the main structure of an FPGA-based test apparatus according to an embodiment of this application. Figure 1 As shown, the testing apparatus in this embodiment of the application is used to test the battery cluster management unit, and mainly includes: The data generation unit generates and distributes simulated cell data.
[0023] An FPGA is provided, which contains at least one AFE simulation unit obtained through different configuration files. The FPGA receives the cell simulation data, responds to the instruction request of the battery cluster management unit, starts the corresponding AFE simulation unit according to the instruction type, processes the cell simulation data according to preset rules, and generates corresponding response data within a preset delay period.
[0024] A communication interface is provided to connect the battery cluster management unit and the FPGA to send the response data generated by the FPGA to the battery cluster management unit.
[0025] In this embodiment, the data generation unit can be a host computer, industrial control computer, embedded board, or other device with data processing capabilities. In a preferred embodiment, the data generation unit is implemented using a host computer, which is an external control device (supporting software running on a PC, etc.). This host computer has a built-in battery cell model. The battery cell model simulates the electrical characteristics of a real battery cell based on a preset battery type (such as lithium iron phosphate, ternary lithium, etc.) and operating conditions, generating simulated battery cell data including voltage, temperature, current, and SOC, and sends it to the FPGA via serial communication.
[0026] Specifically, the cell model simulates the electrical characteristics of a real battery cell based on a preset battery type (such as lithium iron phosphate, ternary lithium, etc.) and operating conditions, generating cell simulation data. This data includes: core state parameters: single cell voltage, charge / discharge current, and real-time temperature; derived state parameters: state of charge (SOC), state of health (SOH), and maximum charge / discharge power (SOP); dynamic response characteristics: charge / discharge curves at different rates, internal resistance changes at different temperatures, and open-circuit voltage (OCV) curves; and complex system behavior: thermal effects and aging patterns of the battery under specific operating conditions. In short, the cell model can also simulate the charge / discharge curves and aging characteristics of a real battery cell. The host computer works in conjunction with the FPGA, allowing the cell model to generate voltage and temperature simulation data for all cells in the cluster, achieving precise adjustment of any voltage and temperature value. In addition, the cell simulation data includes both normal data and fault simulation data. That is, when it is necessary to simulate cell faults (such as overvoltage, undervoltage, overtemperature, etc.), the cell model can generate corresponding fault data to verify the protection logic of the battery cluster management unit.
[0027] The cell model can employ an equivalent circuit model, an electrochemical model, or a data-driven model to generate a dynamic sequence of cell simulation data based on preset battery types (such as lithium iron phosphate, ternary lithium, etc.) and operating conditions (charge-discharge curves, temperature characteristics). This embodiment does not limit the specific model implementation method, as long as it can generate configurable voltage, temperature, and other data.
[0028] In this embodiment, an FPGA (Field-Programmable Gate Array) is a programmable logic device. Users can implement the required digital circuits within the chip by downloading a configuration file (bitstream). During development, testing, and small-batch production, FPGAs offer high flexibility, allowing for easy modification of circuit functions, making them suitable as tools for simulating the final AFE (Analog Front End) product chip. It should be noted that the AFE (Analog Front End) is a core functional chip in the Battery Management Unit (BMU), responsible for collecting data such as cell voltage and temperature, and communicating with the Battery Cluster Management Unit (BCU) via an SPI / isoSPI interface. In this embodiment, the "AFE simulation unit" refers to the hardware logic circuit built within the FPGA using a configuration file to simulate the behavior of a real target AFE chip.
[0029] This application utilizes the hardware programmability of an FPGA to construct a hardware logic circuit that is completely equivalent to the function, timing, and interface level of a real AFE (Analog Front End) chip by configuring its internal logic resources and interconnect switches. This hardware logic circuit executes operations such as SPI communication protocol parsing, CRC verification, and data access in a parallel pipeline manner, and is fully compatible with the target AFE chip in terms of signal behavior, thereby achieving hardware-in-the-loop (HIL) simulation of the AFE chip's behavior. This circuit is physically existing hardware logic, not software simulation. Furthermore, this application embodiment can configure multiple AFE simulation units in the FPGA, each independently simulating a BMU node, thereby achieving multi-node parallel testing of the BCU. Compared to traditional solutions that require connecting multiple real BMUs, this application embodiment can flexibly expand the number of simulation nodes within a single FPGA, significantly improving testing efficiency and scalability.
[0030] In this embodiment, the FPGA and communication interface simulate the behavior of a real Battery Management Unit (BMU), allowing verification of the BCU system without actual battery cells during testing or development. The communication interface is a peripheral hardware device, employing the isoSPI isolated serial peripheral interface (isoSPI), or isolated communication interface for short, to achieve physical layer communication isolation and protocol conversion between the FPGA and the external BCU. Specifically, the isoSPI isolated communication interface converts between SPI bus and daisy-chain communication while providing electrical isolation protection. The isoSPI isolated communication interface has the following key functions: Protocol conversion: converting daisy-chain communication signals from the BCU side into standard SPI signals for FPGA use. Electrical isolation: preventing interference or damage between the high-voltage and low-voltage sides, improving system safety. Bidirectional communication support: receiving read requests from the BCU and transmitting FPGA response data back to the BCU.
[0031] This application, through the collaborative work of the built-in cell model in the host computer and the FPGA simulating AFE behavior, can restore the electrical characteristics and protection logic of real battery clusters under various operating conditions, providing a flexible, efficient, and repeatable hardware-in-the-loop testing environment for the battery management system (BMS) program (especially the BCU level), and verifying its performance under normal, boundary, and fault conditions.
[0032] Compared with existing technologies, the testing device in this application embodiment can complete the verification without building a real battery cluster-level testing environment, significantly reducing testing costs and improving the verification efficiency of BMS software logic. Simultaneously, by simulating the charging and discharging characteristics of real battery cells through a built-in cell model, it can strongly support rapid iteration and software logic optimization during the R&D process.
[0033] In some implementations, the data generation unit also generates simulated cell fault data. This fault data refers to cell voltage, temperature, and other values exceeding normal ranges.
[0034] For example, to test the overvoltage protection logic of the BCU, the host computer can set the voltage of cell 5 (address 5) to 4.5V (exceeding the overvoltage threshold of 3.65V set by the BCU) and the temperature of cell 10 (address 10) to 65℃ (exceeding the overtemperature threshold). The cell model automatically calculates and outputs abnormal values based on the preset fault scenario (e.g., "overvoltage of cell 5"). Alternatively, the test engineer can directly modify the voltage of a cell to 4.5V through the host computer interface, overriding the model's output. After the FPGA receives and stores this fault data, it returns these abnormal values accurately when the BCU polls for them. Upon reading the abnormal data, the BCU should trigger corresponding actions such as overvoltage alarm and overtemperature protection. By observing the BCU's output (e.g., CAN messages, relay control signals), the correctness of its protection logic can be verified. Those skilled in the art can set the overtemperature threshold value according to the needs of the actual application, such as setting it to a value less than 65℃.
[0035] In some implementations, the FPGA includes: a UART for receiving cell simulation data from the data generation unit; an AFE simulation unit, the AFE simulation unit including: a block memory for acquiring the cell simulation data and storing it according to a preset register array; an SPI slave unit connected to the communication interface to receive instruction requests from the battery cluster management unit; and a logic processing unit connected to the block memory and the SPI slave unit respectively, acquiring the instruction request through the SPI slave unit, parsing the instruction, reading the cell simulation data, and generating response data according to corresponding preset rules, and returning the response data to the battery cluster management unit through the SPI slave unit.
[0036] In this embodiment, the FPGA is the core processing unit, responsible for receiving, storing, logically processing, and responding to the simulated battery cell data (internally implementing a serial port unit and an SPI (Serial Peripheral Interface) slave unit). The host computer uses a UART interface for data transmission; therefore, the FPGA needs an internal UART to receive the simulated battery cell data from the host computer. The FPGA is the core controller and simulation engine of this test device, integrating multiple functional units that work together to simulate the behavior of the Battery Management Unit (BMU).
[0037] In some specific embodiments, the UART receives simulated battery cell data from the host computer. After parsing the received data, it is temporarily stored in Block Random Access Memory (BRAM). Asynchronous serial communication is supported, ensuring that the host computer can flexibly configure the battery cell status.
[0038] Specifically, the UART (Universal Asynchronous Receiver / Transmitter) receives battery cell analog data packets from the host computer. These data packets are encapsulated according to a predetermined communication protocol and contain the voltage and temperature values of multiple battery cells. The UART performs serial-to-parallel conversion on the received data packets and parses them according to the predetermined communication protocol to extract the battery cell identifier, parameter type (voltage / temperature), and corresponding values. Specifically, the UART identifies the start of the data frame, battery cell identifier, parameter values, and other fields according to the protocol format, completing the data parsing. The UART writes the voltage and temperature values of each battery cell into the corresponding storage units of the block memory (Block RAM) according to a preset address mapping rule. For example, the voltage value of battery cell 1 can be written to address BASE_ADDR+0, the temperature value of battery cell 1 to address BASE_ADDR+1, and so on, forming a "battery cell parameter lookup table" for subsequent reading by the logic processing unit.
[0039] In this embodiment, the block memory, the SPI slave unit, and the logic processing unit constitute an AFE simulation unit, which is used to simulate the behavior of the battery management unit (BMU) of a battery cluster and is connected to a battery cluster management unit (BCU) under test.
[0040] It should be noted that the block RAM is used to store the cell simulation data sent by the host computer, simulating the internal register array of the target AFE chip. This includes information such as the voltage and temperature of each cell. This data serves as the foundational input for subsequent logic processing. In actual operation, it can support the dynamic updating and retrieval of multiple sets of cell simulation data.
[0041] It should be noted that the logic processing unit is the core algorithm execution unit of the FPGA. It reads simulated cell data from the block RAM and performs logical operations according to the preset battery management unit (BMU) behavior model (including command response logic, state transitions, and sampling frequency) to generate response data. The BMU behavior model defines the functional characteristics that the simulated BMU should possess, including but not limited to: the parsing and response methods for different BCU commands, the switching logic of the BMU operating state (e.g., normal, sleep, fault), the sampling and reporting frequency of the simulated cell data, and the equalization control strategy. The output results include: simulated AFE response data (e.g., cell voltage and temperature values); the state feedback information required when responding to BCU requests (e.g., equalization status, fault flags); and communication protocol processing such as packet error checking (PEC) calculation and frame format encapsulation of the above data to form a standard response frame conforming to the SPI / isoSPI protocol. This unit determines how the FPGA responds to the query requests of the battery cluster management unit (BCU) "like a real BMU."
[0042] Specifically, the aforementioned BMU behavior model is implemented through preset rules configured within the FPGA. The logic processing unit processes the cell simulation data according to the preset rules and generates response data within a preset delay period. In this application, "preset rules" refer to behavioral parameters used to simulate the logic functions of the target AFE chip, including but not limited to: communication protocol rules (command frame format, address mapping, CRC algorithm), data mapping rules (correspondence between cell address and block memory address), diagnostic behavior rules (response content of diagnostic commands), and equalization response rules (processing method of equalization commands), etc. These rules are implemented through the hardware logic of the FPGA, enabling the AFE simulation unit to correctly respond to various instructions from the battery cluster management unit (BCU). As a specific implementation: when the Battery Cluster Management Unit (BCU) sends a read data command (such as read voltage or read temperature), the logic processing unit reads the corresponding cell data from the block memory according to the data mapping rules and returns it; when the BCU sends a diagnostic command, the logic processing unit returns the simulated internal chip diagnostic temperature or status word according to the diagnostic behavior rules; when the BCU sends a configuration command, the logic processing unit updates the internal register according to the communication protocol rules and returns a correct response; when the BCU sends an equalization command, the logic processing unit updates the equalization status register according to the equalization response rules and returns a response.
[0043] In this embodiment, the SPI slave unit is an SPI slave interface of the FPGA internally simulating the target AFE chip, used to communicate with an external communication interface, namely the isoSPI isolated communication interface. The SPI slave unit receives AFE command data (i.e., read / write instructions issued by the BCU) from the isoSPI isolated communication interface. Simultaneously, it sends the response data processed by the logic processing unit back to the battery cluster management unit (BCU) via the SPI slave unit through the isoSPI isolated communication interface.
[0044] In some implementations, the logic processing unit includes: a command parsing unit, which parses the instructions sent by the battery cluster management unit through the SPI slave unit and identifies the instruction type and the target cell address; a data reading unit, which reads cell simulation data from the corresponding address in the block memory according to the target cell address; a response generation unit, which packages the read cell simulation data into response data according to the communication protocol of the target AFE chip; and a timing control unit, which controls the timing of command parsing, data reading, and response generation to ensure compliance with the timing requirements of the target AFE chip.
[0045] Specifically, the target AFE chip refers to the real AFE chip to be simulated, such as the LTC6811. The command parsing unit parses the instructions sent by the Battery Cluster Management Unit (BCU) via the SPI slave unit, identifying the instruction type and the target cell address. For example, according to the target AFE chip's protocol, if the command byte "0x03" sent by the BCU indicates a voltage read operation and "0x05" indicates cell address 5, then the command parsing unit identifies that the voltage of the cell at address 5 needs to be read. After parsing the instruction, the data reading unit reads the cell simulation data from the corresponding address in the block memory according to the parsed target cell address. For example, according to a preset address mapping rule (the voltage of the cell at address 5 is stored at address 0x0010), the voltage value is read from that address. The response generation unit packages the read cell simulation data into a response frame according to the target AFE chip's communication protocol. An exemplary response frame format may include: a frame header (1 byte), a cell address (1 byte), voltage data (2 bytes), temperature data (1 byte), and a CRC checksum (1 byte). This unit is also responsible for adding frame headers / tails, calculating CRC checksums, and parallel-to-serial conversion, and sends the data to the Battery Cluster Management Unit (BCU) via the SPI slave unit. Real AFE chips have strict timing requirements. The timing control unit controls the timing of command parsing, data reading, and response generation to ensure compliance with the timing requirements of the target AFE chip. For example, data is returned after a preset number of clock cycles (e.g., 10 clock cycles) after the BCU sends the command, and each data bit is stably output on a specified edge of the SPI clock (e.g., the rising edge).
[0046] In some embodiments, the FPGA further includes a clock management unit for generating at least one clock, wherein each AFE simulation unit, driven by the corresponding clock, responds to instructions from the battery cluster management unit and generates response data within the preset delay period.
[0047] Specifically, the clock management unit provides operating clocks for each unit within the FPGA to perform corresponding actions within the preset time periods. When the Battery Cluster Management Unit (BCU) of the device under test initiates a cell simulation data read command via a daisy chain, the FPGA retrieves the corresponding data from its local storage with extremely low latency and returns it to the BCU strictly according to the timing requirements of the target AFE chip.
[0048] It should be noted that, under the drive of the clock management unit, in independent parallel mode, multiple AFE simulation units are connected to multiple independent battery cluster management units (BCUs), each responding independently without interference, thus achieving parallel testing. In this application, the AFE simulation units and clock management units are implemented by hardware logic circuits defined in the FPGA configuration file, which has advantages such as nanosecond-level deterministic response latency and strong parallel processing capabilities compared to software simulation schemes.
[0049] In this embodiment, the UART, block memory, SPI slave unit, logic processing unit, AFE simulation unit, and clock management unit inside the FPGA are all implemented by hardware logic circuits defined by the loaded configuration file. Compared with the CPU-based software simulation scheme, it has inherent hardware advantages such as deterministic response delay and strong parallel processing capability.
[0050] In some embodiments, the FPGA includes: a plurality of AFE simulation units, each of which is communicatively connected to a corresponding battery cluster management unit; wherein the plurality of AFE simulation units are configured to operate in a switchable topology, the topology including a parallel topology, a serial topology, or a cascaded topology; in the parallel topology, the plurality of AFE simulation units communicate synchronously and independently with the corresponding battery cluster management unit; in the serial topology, the plurality of AFE simulation units communicate with the corresponding battery cluster management unit in a preset timing sequence; or in the cascaded topology, the plurality of AFE simulation units are connected in series and then communicate with the battery cluster management unit.
[0051] Specifically, this application configures multiple AFE simulation units within an FPGA into switchable parallel, serial, or cascaded topologies, enabling flexible adaptation to various test scenarios and providing significant benefits. In a parallel topology, multiple AFE simulation units communicate synchronously and independently with their corresponding battery cluster management units (BCUs), allowing for parallel testing of multiple BCUs or ports, significantly improving test throughput and efficiency. It also supports independent configuration of different cell operating conditions for each unit, facilitating comprehensive verification of the BCU's protection logic. In a serial topology, multiple AFE simulation units poll and communicate with the BCU according to a preset timing sequence, accurately simulating the serial response behavior of BMU nodes in a real daisy chain. This helps verify the BCU's polling mechanism, address management, and communication timing fault tolerance capabilities. Furthermore, multiple units share the same physical interface, saving hardware resources. In a cascaded topology, multiple AFE simulation units are connected in series and communicate with the BCU, simulating ultra-large-scale battery clusters and even multi-level management architectures across FPGAs. This meets the testing requirements of large-scale energy storage systems and verifies the communication reliability and fault propagation logic of the BCU in a distributed environment. In addition, the three topologies can be dynamically switched through configuration files without replacing hardware, achieving "one machine for multiple uses". This significantly reduces the cost of building the test platform, shortens the R&D iteration cycle, and improves the coverage and automation level of BMS software logic verification.
[0052] In some implementations, the plurality of AFE simulation units may be configured to share the same clock domain or use their own independent clock domains to accommodate different testing requirements.
[0053] Specifically, sharing the same clock domain simplifies design, saves resources, and facilitates synchronous testing; using an independent clock domain allows for flexible adaptation to the clock requirements of different AFE chips, avoiding mutual interference.
[0054] In some implementations, the data generation unit further includes a test sequence generation module, which generates multi-level cell simulation data according to each preset protection threshold of the battery cluster management unit, sends it sequentially to the FPGA, so as to trigger different levels of protection responses of the battery cluster management unit in sequence, and records the response actions of the battery cluster management unit to generate a test report.
[0055] Specifically, the test sequence generation unit is a software module running on a host computer, or a program executed by the host computer's processor. The test sequence generation module can automate the traversal of tests, eliminating the need for manual adjustments to the cell simulation data and improving testing efficiency; it can also verify the correctness of the battery cluster management unit (BCU) response at various protection thresholds, covering the complete protection logic chain.
[0056] In some implementations, the test sequence generation module is also used to collect the output signal of the battery cluster management unit, record the different levels of protection response actions that cross each preset protection threshold, and generate an automated test report.
[0057] Specifically, the test sequence generation module enables closed-loop automated testing: by collecting the actual output signal of the BCU, it automatically compares the result with the expected result, generates a test report, reduces human interpretation errors, and improves test reliability and repeatability.
[0058] In some implementations, the preset protection threshold includes at least one or more of the following: upper voltage threshold, lower voltage threshold, upper temperature threshold, and lower temperature threshold.
[0059] Specifically, preset protection thresholds clearly define threshold types to ensure that tests cover common protection scenarios such as overvoltage, undervoltage, overtemperature, and low temperature, and to fully verify the protection function of the BCU.
[0060] In an energy storage system, a battery cluster contains multiple Battery Management Units (BMUs), which communicate with the Battery Cluster Management Unit (BCU) via a daisy-chain connection. In this embodiment, the host computer sends simulated cell voltage and temperature data to the FPGA, which receives and stores the data in its internal Block RAM. The FPGA receives the daisy-chain signals from the BCU through an isolated communication interface, which converts the daisy-chain signals into SPI signals and sends them to the FPGA. The SPI slave unit inside the FPGA parses the command words in the SPI signals and, according to the protocol of the simulated target AFE chip, returns corresponding diagnostic information or cell simulation data to the BCU.
[0061] like Figure 2 As shown in the embodiments of this application, an FPGA-based testing method is also provided for testing a battery cluster management unit, including: Step S110: Generate and distribute cell simulation data.
[0062] Step S120: By using different configuration files, at least one AFE simulation unit is obtained in the FPGA to receive and store the cell simulation data. In response to the instruction request of the battery cluster management unit, the corresponding AFE simulation unit is started according to the instruction type, the cell simulation data is processed according to preset rules, and corresponding response data is generated within a preset delay period.
[0063] Step S130: Send the response data to the corresponding battery cluster management unit.
[0064] Step S110 of this embodiment can be implemented using the data generation unit described above to generate and send cell simulation data. Step S120 can be implemented using the FPGA described above to receive the cell simulation data, respond to the instruction request from the battery cluster management unit, start the corresponding AFE simulation unit according to the instruction type, process the cell simulation data according to preset rules, and generate corresponding response data within a preset delay period. At least one AFE simulation unit is obtained within the FPGA through different configuration files. Step S130 can be implemented using the communication interface described above to send the response data generated by the FPGA to the battery cluster management unit. Other functional modules or units that can implement the above steps are also within the scope of protection of this application.
[0065] In some embodiments, the method further includes: Step S140: Generate and distribute multi-level cell simulation data based on the protection threshold of the battery cluster management unit.
[0066] Step S140 in this embodiment can employ a data generation unit to generate multi-level cell simulation data based on the protection threshold of the battery cluster management unit. The host computer sequentially sends each level of data to the FPGA via UART, and the FPGA updates the block RAM. For example, if the overvoltage threshold of the battery cluster management unit is 3.65V and the first-level overvoltage threshold is 4.0V, the simulated cell voltage gradually increases from 3.5V to 4.3V in steps of 0.1V.
[0067] After periodically reading the cell simulation data, the Battery Cluster Management Unit (BCU) will output corresponding protection actions (such as alarm messages and relay disconnection signals) based on the current voltage value.
[0068] Step S150: Real-time acquisition of the corresponding protection action signal output by the battery cluster management unit after reading the cell simulation data.
[0069] Specifically, step S150 can use the aforementioned data generation unit, whereby the host computer collects the protection action signal output by the battery cluster management unit (BCU) in real time through an external communication interface (such as a CAN card or I / O acquisition card).
[0070] Step S160: Compare and label the protection actions output by the battery cluster management unit with the expected actions, and generate a test report.
[0071] Specifically, step S160 can utilize the aforementioned data generation unit, whereby the host computer compares the actual actions of the battery cluster management unit (BCU) at each voltage point with the expected actions. Expected actions include: no action when voltage < 3.65V, sending an overvoltage alarm when voltage is between 3.65V and 4.0V, and disconnecting the charging relay when voltage > 4.0V. Actions matching the expected actions are marked as pass, while actions different from the expected actions are marked as fail. Information such as test time, threshold points, expected actions, actual actions, judgment results, and failure reasons are compiled into a structured report (e.g., HTML / PDF / Excel), supporting storage and printing.
[0072] Example 1, as Figure 3 As shown, the battery cluster management unit is tested using the FPGA-based test device described above, including the following steps: Step S100: Initialization and cell simulation data configuration.
[0073] After the test device is powered on, it initializes and configures the cell simulation data. The host computer sends a set of preset cell parameters (such as voltage and temperature) to the FPGA via a UART connection to simulate the state of a real battery pack. This data is called "initialized cell simulation data," representing the static attributes of all cells at the initial moment. After the data is received by the UART, it is written into the internal block RAM of the FPGA for storage.
[0074] Step S200: Battery Cluster Management Unit (BCU) power-on diagnostics and FPGA response.
[0075] The Battery Cluster Management Unit (BCU) issues a standard AFE power-on diagnostic command via the daisy-chain communication protocol. This command is designed to confirm the existence and normal operation of downstream BMU nodes. The daisy-chain signal is converted to SPI format via the isoSPI communication interface and transmitted to the FPGA.
[0076] Step S300: After the FPGA receives the diagnostic command.
[0077] The diagnostic logic processing unit is activated. A corresponding response frame is generated according to preset rules (e.g., returning simulated internal chip diagnostic temperature, correct read / write configuration response, passive equalization voltage response, etc.).
[0078] Step S400: The Battery Cluster Management Unit (BCU) requests cell simulation data and the FPGA responds in real time.
[0079] After completing the diagnostics, the Battery Cluster Management Unit (BCU) begins periodically polling the real-time data of each cell. Upon receiving the request, the FPGA extracts the voltage, temperature, and other data of the corresponding cell from the Block RAM. Simultaneously, it calls the logic processing unit to perform necessary formatting, checksum calculation, and other operations. Finally, it encapsulates the read data into a standard message conforming to the communication protocol (including data fields, PEC checksums, etc.) and sends it to the isoSPI communication interface via the SPI slave unit. The isoSPI communication interface converts it into a daisy-chain format and returns it to the Battery Cluster Management Unit (BCU).
[0080] Step S500: Dynamic data update and working condition simulation.
[0081] During device operation, the host computer can send new cell simulation data again via UART. This data is received by the FPGA and updates the original records in the block memory (Block RAM), supporting dynamic fault injection and complex operating condition simulation, thereby improving the flexibility and realism of the test.
[0082] Through the above steps, the FPGA directly processes SPI communication using hardware logic, eliminating operating system scheduling delays and achieving microsecond-level response times. The host computer can modify cell parameters at any time via UART, simulating various operating conditions without hardware modifications. It can also sequentially trigger threshold logic based on specific project requirements, achieving complete automated testing and report generation, significantly improving verification efficiency. The system supports mainstream AFE chip communication protocols and daisy-chain communication protocols, offering wide compatibility. Multiple FPGAs can be connected in parallel to simulate multiple clusters of BMU nodes, making it suitable for large-scale energy storage system testing platforms.
[0083] The above description is only a preferred embodiment of this application. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of this application, and these improvements and modifications should also be considered within the scope of protection of this application.
Claims
1. A test device based on FPGA, characterized in that, Used for testing the battery cluster management unit, including: The data generation unit generates and distributes simulated cell data. An FPGA is provided, which contains at least one AFE simulation unit obtained through different configuration files. The FPGA receives the cell simulation data, responds to the instruction request of the battery cluster management unit, starts the corresponding AFE simulation unit according to the instruction type, processes the cell simulation data according to preset rules, and generates corresponding response data within a preset delay period. A communication interface is provided to connect the battery cluster management unit and the FPGA to send the response data generated by the FPGA to the battery cluster management unit.
2. The testing apparatus according to claim 1, characterized in that, The FPGA includes: UART receives cell simulation data sent by the data generation unit; An AFE simulation unit, the AFE simulation unit comprising: The block memory acquires the simulated data of the battery cell and stores it according to a preset register array; An SPI slave unit is connected to the communication interface to receive instruction requests from the battery cluster management unit; In addition, a logic processing unit is connected to the block memory and the SPI slave unit respectively. It obtains the instruction request through the SPI slave unit, parses the instruction, reads the cell simulation data and generates response data according to the corresponding preset rules, and returns the response data to the battery cluster management unit through the SPI slave unit.
3. The testing apparatus according to claim 2, characterized in that, The logic processing unit includes: The command parsing unit parses the instructions sent by the battery cluster management unit through the SPI slave unit and identifies the instruction type and the target cell address. The data reading unit reads the simulated cell data from the corresponding address in the block memory according to the target cell address; The response generation unit packages the read cell simulation data into response data according to the communication protocol of the target AFE chip; The timing control unit controls the timing of command parsing, data reading, and response generation to ensure compliance with the timing requirements of the target AFE chip.
4. The testing apparatus according to any one of claims 1 to 3, characterized in that, The FPGA also includes: A clock management unit is used to generate at least one clock. Each AFE analog unit responds to the instructions of the battery cluster management unit under the drive of the corresponding clock and generates response data within the preset delay period.
5. The testing apparatus according to claim 2, characterized in that, The FPGA includes: Multiple AFE simulation units, each of which is communicatively connected to a corresponding battery cluster management unit; The plurality of AFE simulation units are configured to operate in a switchable topology, which includes a parallel topology, a serial topology, or a cascaded topology. In a parallel topology, the multiple AFE simulation units communicate synchronously and independently with their corresponding battery cluster management units; In a serial topology, the multiple AFE simulation units communicate with their corresponding battery cluster management units in a preset timing sequence; or In a cascaded topology, the multiple AFE simulation units are connected in series and then communicate with the battery cluster management unit.
6. The testing apparatus according to claim 5, characterized in that, The multiple AFE simulation units can be configured to share the same clock domain or use their own independent clock domains to adapt to different testing requirements.
7. The testing apparatus according to any one of claims 1 to 3, characterized in that, The data generation unit further includes: The test sequence generation module is used to generate multi-level cell simulation data according to the preset protection thresholds of the battery cluster management unit, and send it to the FPGA in sequence to trigger different levels of protection responses of the battery cluster management unit in turn, record the response actions of the battery cluster management unit, and generate a test report.
8. The testing apparatus according to claim 7, characterized in that, The test sequence generation module is also used to collect the output signal of the battery cluster management unit, record the different levels of protection response actions that cross each preset protection threshold, and generate an automated test report.
9. The testing apparatus according to claim 7, characterized in that, The preset protection threshold includes at least: Any one or more of the following: upper voltage threshold, lower voltage threshold, upper temperature threshold, and lower temperature threshold.
10. An FPGA-based testing method, characterized in that, Used for testing the battery cluster management unit, including: Generate and distribute cell simulation data; By using different configuration files, at least one AFE simulation unit is obtained within the FPGA to receive and store the cell simulation data. In response to the instruction request from the battery cluster management unit, the corresponding AFE simulation unit is started according to the instruction type, the cell simulation data is processed according to preset rules, and corresponding response data is generated within a preset delay period. The response data is sent to the corresponding battery cluster management unit.