Battery management system hardware-in-the-loop test system and test method

Abstract

The invention provides a battery management system hardware-in-the-loop test system and method, and the system comprises an intelligent case generation engine which generates a test case set through a combined test algorithm module and a reinforcement learning agent module according to the test demands of a user; the dynamic model scheduler is used for dynamically switching the battery models according to the test stage; the parallelization controller is used for intelligently analyzing and decomposing the test case set into a plurality of mutually independent test sub-tasks by applying a containerization technology and executing the test sub-tasks in parallel; the test executor obtains test case scripts of the test subtasks from the parallelization controller and sends excitation signals to the hardware interface layer strictly according to a time sequence; the hardware interface layer comprises a virtualized hardware adaptation layer and is in signal connection with the battery management system to be tested; and the real-time database is used for storing the original data from the test actuator, the task state of the parallelization controller, the model parameters of the dynamic model scheduler and the response data collected from the battery management system in real time.

Description

Technical Field

[0001] This application relates to a hardware-in-the-loop testing system and method for a battery management system, belonging to the field of hardware-in-the-loop testing technology. Background Technology

[0002] With the development of electric construction machinery technology, the battery system, as the core power component of pure electric construction machinery, directly determines the performance and competitiveness of the main unit and the satisfaction of end users. Before the battery system is launched on the market, the battery management system (BMS), as the "brain" of the battery system, requires particularly important hardware-in-the-loop testing and verification of its various functions.

[0003] In related technologies, the hardware-in-the-loop testing system for battery management systems in the construction machinery field faces the following challenges: ① Electric construction machinery operates under complex conditions with drastic changes in battery load, requiring extremely high fidelity and real-time computing capabilities from the hardware-in-the-loop simulation model; ② Construction machinery battery packs have large capacities and numerous series and parallel cells (potentially up to hundreds), making the simulation of their dynamic behavior and fault scenarios more complex, thus requiring a very large-scale hardware-in-the-loop simulation model; ③ The design of BMS for construction machinery varies significantly among different manufacturers or models (e.g., hardware interfaces), and there is a lack of universal or rapidly configurable hardware-in-the-loop testing platforms on the market that can quickly adapt to various BMSs. Summary of the Invention

[0004] In view of at least one of the above technical problems, this application provides a hardware-in-the-loop testing system and method for a battery management system. Through intelligent scheduling and resource virtualization, the system achieves highly parallel and adaptive execution of test tasks, thereby improving test efficiency and coverage and reducing test economic costs.

[0005] To solve the above-mentioned technical problems, the technical solution adopted in this application is: According to a first aspect of this application, a hardware-in-the-loop testing system for a battery management system is provided, including: It includes a top-down intelligent decision-making layer, coordination and execution layer, hardware interface layer, and data core layer; The intelligent decision-making layer includes: an intelligent test case generation engine, which generates test case sets by using a combined test algorithm module and a reinforcement learning agent module according to user test requirements; and a dynamic model scheduler, which has a built-in multi-level battery model library containing electrochemical models, equivalent circuit models and data-driven models, and is used to dynamically switch battery models according to the test phase. The coordination and execution layer includes: a parallelization controller, which receives a test case set from the intelligent test case generation engine and uses containerization technology to intelligently parse and decompose the test case set into multiple independent and resource-isolated test subtasks for parallel execution; and a test executor, which obtains the test case scripts for each test subtask from the parallelization controller and sends stimulus signals to the hardware interface layer in strict accordance with the timing sequence. The hardware interface layer includes a virtualized hardware adaptation layer for signal connection with the battery management system under test; The data core layer includes a real-time database for storing raw data from the test executor, the task status of the parallel controller, the model parameters of the dynamic model scheduler, and response data collected from the battery management system in real time.

[0006] According to a second aspect of this application, a hardware-in-the-loop testing method for a battery management system is provided, wherein the method, based on the aforementioned hardware-in-the-loop testing system for the battery management system, comprises: Input user testing requirements, which include multiple test parameters; The intelligent test case generation engine generates test case sets based on user testing requirements using a combined testing algorithm module and a reinforcement learning agent module. The dynamic model scheduler determines the testing phase based on user testing needs and dynamically switches battery models. The parallelization controller receives the test case set from the intelligent test case generation engine, and uses containerization technology to intelligently parse and decompose the test case set into multiple independent and resource-isolated test subtasks for parallel execution, and stores the task status and test results in a real-time database. The test executor obtains the test case scripts for each test subtask from the parallelization controller and sends stimulus signals to the virtualization hardware adaptation layer in strict accordance with the timing sequence. The virtualized hardware adaptation layer converts the excitation signal into a physical signal and sends it to the battery management system under test.

[0007] In some embodiments, the battery management system hardware-in-the-loop testing method further includes: The response signals from the battery management system under test are uploaded to the real-time database through the virtualization hardware adaptation layer for analysis by the intelligent use case generation engine.

[0008] The beneficial effects achieved by this application are as follows: This application has the following advantages: 1. Significantly shortens the testing cycle and reduces time costs. The intelligent test case generation engine significantly reduces redundant testing through algorithms, avoiding a large amount of unnecessary repetitive work. Dynamic precision model scheduling intelligently switches models according to different testing stages, ensuring accuracy in key scenarios while reducing model computation time and resolving the conflict between high-precision models and real-time performance. The parallel testing architecture decomposes traditional serial test tasks and executes them concurrently, shortening the overall testing cycle.

[0009] 2. Significantly improve test coverage and quality A multi-level model library and intelligent scheduling ensure full-scenario coverage from calibration to extreme operating conditions, improving test coverage for boundary conditions and extreme operating conditions, and making it easier to discover potential defects. Reinforcement learning-optimized testing strategies prioritize high-risk areas, improving defect detection rates and significantly enhancing testing effectiveness and product quality. Dynamic fault chain injection surpasses traditional preset fault libraries, simulating more complex and realistic fault scenarios, thereby enabling deeper verification of the BMS's fault handling mechanisms.

[0010] 3. Break free from hardware constraints and achieve "one platform, multiple tests" The virtualized hardware adaptation layer, through abstraction and FPGA reconfiguration technologies, reduces hardware switchover time from hours to minutes, enabling rapid and seamless switching between different BMS models. This design significantly reduces hardware investment costs and dependence on dedicated hardware, making the test platform a flexibly configurable, general-purpose asset adaptable to future new product testing needs.

[0011] 4. A continuously optimized testing system The system is no longer a static, one-way testing tool, but a data-driven intelligent closed loop. The real-time database aggregates all test data, providing learning data for the reinforcement learning agent, enabling it to continuously learn from historical test results and optimize testing strategies.

[0012] 5. Overall reduction in development and testing costs This not only directly reduces hardware costs, but more importantly, it significantly shortens the development and verification cycle, enabling products to enter the market faster and seize the initiative. Attached Figure Description

[0013] Figure 1 This is a schematic diagram of a hardware-in-the-loop test system for a battery management system provided in an embodiment of this application; Figure 2 This is a schematic diagram illustrating the implementation process of the intelligent use case generation engine provided in the embodiments of this application; Figure 3 This is a schematic diagram illustrating the implementation process of the dynamic model scheduler provided in the embodiments of this application; Figure 4 This is a schematic diagram of the implementation process of the parallelization controller provided in the embodiments of this application; Figure 5 This is a schematic diagram illustrating the implementation process of the virtualization hardware adaptation layer provided in this application embodiment. Detailed Implementation

[0014] The present application will be further described below with reference to the accompanying drawings. The following embodiments are only used to more clearly illustrate the technical solution of the present application, and should not be used to limit the scope of protection of the present application.

[0015] In the description of this invention, "several" means one or more, "multiple" means two or more, "greater than," "less than," and "exceeding" are understood to exclude the stated number, while "above," "below," and "within" are understood to include the stated number. The use of "first" and "second" in the description is merely for distinguishing technical features and should not be construed as indicating or implying relative importance, or implicitly indicating the number of indicated technical features, or implicitly indicating the order of the indicated technical features.

[0016] In the description of this invention, the terms "one embodiment," "some embodiments," "illustrative embodiment," "example," "specific example," or "some examples," etc., refer to specific features, structures, materials, or characteristics described in connection with that embodiment or example, which are included in at least one embodiment or example of the invention. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.

[0017] The existing hardware-in-the-loop testing (HIL) technology solutions for battery management systems mainly consist of the following parts: 1. Hardware connection: Based on the BMS hardware product interface, corresponding test harnesses are made to connect to the resources of the hardware-in-the-loop testing equipment; 2. Simulation model: A single battery simulation model is used, such as a high-precision electrochemical simulation model or a simplified equivalent circuit model; 3. Software platform: Responsible for test management and automated execution.

[0018] Existing hardware-in-the-loop testing solutions for battery management systems have the following problems: Low computational efficiency of the model: High-precision electrochemical models are computationally complex and have poor real-time performance; simplified models cannot cover extreme operating conditions.

[0019] Redundant test cases: Manually writing test cases is time-consuming and difficult to cover scenarios with multiple coupled parameters.

[0020] Rigid hardware resources: Fixed hardware interfaces cannot be adapted to multiple BMS models, resulting in high switching costs.

[0021] Single fault injection: It relies on a pre-defined fault library, making it difficult to dynamically generate complex fault chains.

[0022] Data analysis is lagging: Test results rely on manual analysis and cannot provide real-time feedback for optimization strategies.

[0023] This application provides a hardware-in-the-loop testing system that utilizes a dynamic precision adjustment model, a parallelized test architecture, and intelligent test case generation. This application breaks away from the traditional serial and rigid testing process, achieving highly parallel and adaptive execution of test tasks through intelligent scheduling and resource virtualization, thereby improving testing efficiency and coverage while reducing testing costs.

[0024] This application provides a hardware-in-the-loop testing system for a battery management system, comprising a top-down intelligent decision-making layer, a coordination and execution layer, a hardware interface layer, and a data core layer. The intelligent decision-making layer includes: The intelligent test case generation engine is used to generate test case sets based on user testing requirements by combining test algorithm modules and reinforcement learning agent modules; The dynamic model scheduler has a built-in multi-level battery model library containing electrochemical models, equivalent circuit models, and data-driven models, which is used to dynamically switch battery models according to the testing phase. The coordination execution layer includes a parallelization controller, a parallelization controller, and a hardware interface layer; The parallelization controller receives the test case set from the intelligent test case generation engine and uses containerization technology to intelligently parse and decompose the test case set into multiple independent and resource-isolated test subtasks for parallel execution. The test executor obtains the test case scripts for each test subtask from the parallelization controller and sends stimulus signals to the hardware interface layer in strict accordance with the timing sequence. The hardware interface layer includes a virtualized hardware adaptation layer for signal connection with the battery management system under test.

[0025] The data core layer includes a real-time database for storing raw data from the test executor, the task status of the parallel controller, the model parameters of the dynamic model scheduler, and response data collected from the battery management system in real time.

[0026] In this embodiment, as Figure 1 As shown, the intelligent decision-making layer, coordination and execution layer, hardware interface layer and data core layer communicate and interact in real time through a high-speed data bus; 1. Intelligent Decision Layer: This layer is the brain of the system, responsible for generating and optimizing testing strategies, and is located at the top of the architecture.

[0027] Intelligent Test Case Generation Engine: The starting point for testing tasks. This engine receives user-defined test requirements, parameter boundaries, and compliance standards. Internally, it integrates a combinatorial testing algorithm module and a reinforcement learning agent module. The combinatorial testing algorithm efficiently generates a minimal set of test cases covering all parameter interactions, greatly reducing redundancy. The reinforcement learning agent dynamically adjusts the priority and execution order of test cases by analyzing historical test data (such as past failure cases), ensuring that high-risk, failure-prone scenarios are tested first, thereby maximizing testing efficiency.

[0028] Dynamic Model Scheduler: The core of model computation efficiency optimization. This module is the core intelligent unit for achieving a balance between testing efficiency and accuracy. Its operation is not a simple model switching, but an intelligent decision-making process based on rules and prediction. Internally, it maintains a multi-level battery model library including high-precision electrochemical models, simplified equivalent circuit models, and data-driven models. The scheduler itself is a lightweight microservice that continuously listens for real-time requests from the test executor and intelligently selects and switches the most suitable battery simulation model based on the accuracy and real-time requirements of the test cases to be executed. For example, it calls the electrochemical model when testing SOC accuracy; switches to the equivalent circuit model when performing a large number of fault injection regression tests; and calls the data-driven model to quickly predict the battery's temperature rise / fall curve when facing extreme high and low temperature conditions.

[0029] 2. Coordination and execution layer: This layer is the central nervous system of the system, responsible for receiving instructions from the decision-making layer and driving the hardware to execute.

[0030] Parallel Controller: The "Traffic Commander" of Test Tasks. It transforms traditional "single-lane serial testing" into "multi-lane parallel testing," with the core being efficient resource scheduling and task orchestration. It receives test case sets from the intelligent test case generation engine and uses containerization technology to intelligently parse and decompose them. It breaks down a large test task into multiple independent, resource-isolated test subtasks. These subtasks are distributed to different computing containers for execution, and finally, the controller aggregates the results, thereby maximizing the utilization of computing resources and significantly reducing overall test time.

[0031] Test executor: As the engine for running test cases, it obtains the test case scripts for each test subtask from the parallelization controller and sends stimulus signals (such as analog current and voltage output, CAN messages, etc.) to the hardware interface layer in strict accordance with the timing.

[0032] 3. Hardware Interface Layer: This layer serves as a bridge connecting the system to the physical world, enabling flexibility and reconfigurability of hardware resources.

[0033] Virtualized Hardware Adapter Layer: This application addresses the pain point of rigid hardware I / O resources in hardware-in-the-loop test platforms through this module. This module acts as a "universal adapter" connecting the test software and BMS hardware, its core being the implementation of a "soft" definition of the test platform through hardware abstraction. The virtualized hardware adapter layer builds a unified software abstraction layer on top of physical I / O boards (such as PXI boards). For example, when testing a new BMS, if a sensor interface changes from CAN communication to Ethernet communication, traditional solutions require replacing the hardware module and rewiring. In this solution, engineers only need to map the sensor's signal points from the "CAN database" file to the "Ethernet" service description file in the configuration interface of the virtualized hardware adapter layer. The field-programmable gate array (FPGA) core of the virtualized hardware adapter layer recompiles its internal logic in real time according to the new configuration, packages and sends the excitation signals (such as a temperature value) generated by the test software according to the Ethernet protocol, and simultaneously unpacks and uploads the Ethernet messages returned from the BMS to the test software. For the BMS, it perceives a real Ethernet device; for the upper-layer testing software, it still operates on a unified "temperature" signal variable. This achieves the goal of "one set of HIL device hardware, compatible with multiple BMSs," significantly reducing costs and switchover time.

[0034] 4. Data Core Layer Real-time database: As the information hub and data lifeline of the entire architecture, it stores raw data from the test executor, task status of the parallelization controller, model parameters of the dynamic model scheduler, and response data collected from the BMS in real time. It provides unified, high-speed data access services for all modules, ensuring data consistency and real-time performance of the entire system in a parallelized testing environment.

[0035] 5. The object being tested BMS under test: As the object under test, it is connected to the hardware interface layer of the hardware-in-the-loop tester through physical wiring harness, receives the excitation signals generated by the simulated battery model, and reports its decision and control signals, thus forming a complete, closed-loop test environment.

[0036] In some embodiments, such as Figure 2 As shown, in the intelligent use case generation engine, The combinatorial testing algorithm module is used to generate a minimal set of test cases that can cover all pairwise interactions of parameters in the user's testing requirements, based on the Pairwise combinatorial testing algorithm. The reinforcement learning agent module is used to dynamically optimize the priority of test cases in the minimum test case set, thereby obtaining the optimized test sequence and forming a test case set.

[0037] An exemplary implementation of the intelligent test case generation engine: The user inputs test parameters on the front-end interface (e.g., temperature range -30℃ to 60℃, SOC range 10% to 90%, charge / discharge rate 0.5C to 2C). The engine backend first runs a Pairwise combination test algorithm to generate a minimal set of test cases that covers all pairwise parameter interactions, streamlining from tens of thousands of possible combinations to a few hundred core scenarios. Subsequently, a reinforcement learning agent begins its work. The agent's "state" is the current testing progress and the types of defects discovered, its "action" is selecting the next test case to execute, and its "reward" is the severity of the discovered new defect. For example, if historical data shows that the "low temperature, high SOC" combination easily leads to overvoltage alarms, the reinforcement learning agent will assign higher priority to such test cases and proactively generate more granular parameter steps (e.g., at -30℃, SOC increases from 85% to 92% in 1% increments) for precise testing.

[0038] In some embodiments, such as Figure 3 As shown, the dynamic model scheduler is specifically used for: In response to the test requirements issued by the test executor, the dynamic model scheduler parses the test requirements and determines the test phases; wherein the test phases include the calibration phase, the functional verification phase, and the extreme condition phase. If the testing phase is the calibration phase, the electrochemical model is used for simulation. If the testing phase is the functional verification phase, the equivalent circuit model is used for simulation. If the testing phase is the extreme operating condition phase, the data-driven model is invoked for simulation. The simulation results are returned to the test executor.

[0039] Furthermore, the dynamic model scheduler is also used to: under extreme operating conditions, if the data-driven model predicts the risk of thermal runaway, send an alarm to the test executor to trigger the fault protection mechanism of the BMS.

[0040] An exemplary dynamic model scheduler implementation: When the test executor initiates a request for a "battery pack fast charging cycle life test", the dynamic model scheduler will make the following intelligent judgment: ① Calibration stage -- In order to obtain accurate initial state of battery aging, it prioritizes calling high-precision electrochemical models to simulate the first few charge-discharge cycles in order to establish reliable baseline data; ② Functional Verification Phase – When entering the stage of hundreds or thousands of cyclic tests, the requirement for instantaneous accuracy in a single cycle decreases, while the requirements for overall trend and calculation speed increase. At this time, the scheduler automatically switches to the equivalent circuit model, increasing the simulation speed by an order of magnitude.

[0041] ③ Extreme operating condition stage – When real-time data monitoring indicates that the battery voltage or temperature is approaching the preset safety boundary, the scheduler will instantly invoke a data-driven model trained on a long short-term memory network to quickly predict parameter change trends within the next few seconds. If a risk of thermal runaway is predicted, an alarm will be immediately sent to the test actuator, triggering the BMS's fault protection mechanism.

[0042] In some embodiments, such as Figure 4 As shown, the parallelization controller receives a test case set from the intelligent test case generation engine and uses containerization technology to intelligently parse and decompose the test case set into multiple independent, resource-isolated test subtasks for parallel execution, specifically including: Dependency analysis is performed through static code scanning and dynamic resource requirement analysis, and the test case set is decomposed into multiple independent test subtasks; Containerization technology is used to create isolated containers for each test subtask, allocate computing resources, and execute them in parallel within each container; The task status and test results of all containers are cached in a real-time database, summarized, and used to generate test reports.

[0043] An exemplary parallelization controller implementation: After receiving the test case set from the intelligent test case generation engine, the parallelization controller first performs dependency analysis through static code scanning and dynamic resource requirement analysis, decomposing the test task into multiple independent sub-tasks (e.g., SOC estimation, high-voltage interlock detection, charge / discharge balancing testing, etc.). Subsequently, it utilizes containerization technology to quickly create isolated, lightweight execution environments for each sub-task. The parallelization controller monitors the host machine's CPU, memory, and I / O resources in real time, and, like an intelligent scheduling system, schedules different container tasks to idle computing cores for parallel execution. All containers synchronize task status and test results through a shared real-time database, ensuring global consistency.

[0044] In some embodiments, such as Figure 5 As shown, when the current sensor interface changes from CAN communication to Ethernet communication, the virtualization hardware adaptation layer needs to perform the following actions: (1) In the configuration phase, the execution actions of the virtualization hardware adaptation layer include: Step 1: In the virtualization hardware adaptation layer configuration interface, map the signal points from the "CAN database" to the "Ethernet" service description file in a graphical way; Step 2: The protocol mapper establishes signal conversion rules based on the configuration information; Step 3: The FPGA configuration generator compiles the mapping rules into hardware-executable logic code; Step 4: The compiled configuration is loaded into the FPGA programmable logic, completing the hardware reconfiguration.

[0045] (2) During the test execution phase, the execution actions of the virtualization hardware adaptation layer include: When the signal flow is in the forward direction (upper-layer test software → BMS): the upper-layer test software generates the original current excitation signal; the signal abstraction engine receives the original excitation signal and standardizes it into a standardized signal of a unified format; the protocol mapper converts the standardized signal into the target protocol format -- Ethernet protocol data packet according to preset rules; the FPGA executes protocol stack processing to generate physical signals that conform to the physical layer specifications; and sends the physical signals to the battery management system under test through the Ethernet port. When the signal flow is in reverse (BMS → upper-level test software): the response signal of the battery management system under test returns a physical signal through the physical port; the FPGA receives the physical signal and initially parses it into the target protocol format - Ethernet protocol data packet; the signal abstraction engine restores the target protocol format - Ethernet protocol data packet into a standardized signal of the unified format; the standardized signal is returned to the upper-level test software for further processing.

[0046] "Fault Chain" Injection Simulation Implementation Example: The "fault chain" injection simulation function mentioned in this application is not a simple simulation of a single fault, but rather a reproduction of complex, cascading failure scenarios in the real world, thereby deeply verifying the fault diagnosis and fault tolerance capabilities of the BMS. For example, an engineer could design a scenario like this: Step ① (Hidden Fault): Simulate a slow increase in the internal resistance of a battery cell (±10%), which is a soft fault that is difficult for the BMS to detect in the early stages.

[0047] Step ② (Triggering condition): When the battery pack is discharging at a high current (2C), the voltage of the cell will drop sharply due to the abnormal internal resistance of the cell.

[0048] Step ③ (Chain Reaction): When the BMS detects that the battery cell is undervoltage and activates protection measures (such as reducing the allowable discharge current), the fault injection module immediately simulates intermittent packet loss on the CAN communication bus, interfering with the normal communication between the BMS and the vehicle controller.

[0049] Step 4 (Observation and Evaluation): Test the system to evaluate whether the BMS can still make safe decisions (such as entering limp mode) and record accurate fault codes under this series of complex faults.

[0050] like Figure 2 As shown in the illustration, this application also provides a hardware-in-the-loop testing method for a battery management system. Based on the aforementioned hardware-in-the-loop testing system for the battery management system, the method includes: Input user testing requirements, which include multiple test parameters; The intelligent test case generation engine generates test case sets based on user testing requirements using a combined testing algorithm module and a reinforcement learning agent module. The dynamic model scheduler determines the testing phase based on user testing needs and dynamically switches battery models. The parallelization controller receives the test case set from the intelligent test case generation engine, and uses containerization technology to intelligently parse and decompose the test case set into multiple independent and resource-isolated test subtasks for parallel execution, and stores the task status and test results in a real-time database. The test executor obtains the test case scripts for each test subtask from the parallelization controller and sends stimulus signals to the virtualization hardware adaptation layer in strict accordance with the timing sequence. The virtualized hardware adaptation layer converts the excitation signal into a physical signal and sends it to the battery management system under test. The response signals from the battery management system under test are uploaded to a real-time database through a virtualization hardware adaptation layer for analysis by the intelligent test case generation engine. This optimizes subsequent testing, forming a continuously self-optimizing intelligent closed loop.

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

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

[0053] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0054] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0055] 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 technical principles of this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. A hardware-in-the-loop testing system for a battery management system, characterized in that, It includes a top-down intelligent decision-making layer, coordination and execution layer, hardware interface layer, and data core layer; The intelligent decision-making layer includes: an intelligent test case generation engine, which generates test case sets by using a combined test algorithm module and a reinforcement learning agent module according to user test requirements; and a dynamic model scheduler, which has a built-in multi-level battery model library containing electrochemical models, equivalent circuit models and data-driven models, and is used to dynamically switch battery models according to the test phase. The coordination and execution layer includes: a parallelization controller, which receives a test case set from the intelligent test case generation engine and uses containerization technology to intelligently parse and decompose the test case set into multiple independent and resource-isolated test subtasks for parallel execution; and a test executor, which obtains the test case scripts for each test subtask from the parallelization controller and sends stimulus signals to the hardware interface layer in strict accordance with the timing sequence. The hardware interface layer includes a virtualized hardware adaptation layer for signal connection with the battery management system under test; The data core layer includes a real-time database for storing raw data from the test executor, the task status of the parallel controller, the model parameters of the dynamic model scheduler, and response data collected from the battery management system.

2. The battery management system hardware-in-the-loop testing system according to claim 1, characterized in that, In the intelligent use case generation engine The combinatorial testing algorithm module is used to generate a minimal set of test cases that can cover all pairwise interactions of parameters in the user's testing requirements, based on the Pairwise combinatorial testing algorithm. The reinforcement learning agent module is used to dynamically optimize the priority of test cases in the minimum test case set, thereby obtaining the optimized test sequence and forming a test case set.

3. The battery management system hardware-in-the-loop testing system according to claim 1, characterized in that, The dynamic model scheduler is specifically used for: In response to the test requirements issued by the test executor, the dynamic model scheduler parses the test requirements and determines the test phases; wherein the test phases include the calibration phase, the functional verification phase, and the extreme condition phase. If the testing phase is the calibration phase, the electrochemical model is used for simulation. If the testing phase is the functional verification phase, the equivalent circuit model is used for simulation. If the testing phase is the extreme operating condition phase, the data-driven model is invoked for simulation. The simulation results are returned to the test executor.

4. The battery management system hardware-in-the-loop testing system according to claim 3, characterized in that, The dynamic model scheduler is also used for: Under extreme operating conditions, if the data-driven model predicts the risk of thermal runaway, an alarm is sent to the test actuator to trigger the fault protection mechanism of the BMS.

5. The battery management system hardware-in-the-loop testing system according to claim 1, characterized in that, The parallelization controller receives a test case set from the intelligent test case generation engine and uses containerization technology to intelligently parse and decompose the test case set into multiple independent, resource-isolated test subtasks for parallel execution, specifically including: Dependency analysis is performed through static code scanning and dynamic resource requirement analysis, and the test case set is decomposed into multiple independent test subtasks; Containerization technology is used to create isolated containers for each test subtask, allocate computing resources, and execute them in parallel within each container; The task status and test results of all containers are cached in a real-time database, summarized, and used to generate test reports.

6. The battery management system hardware-in-the-loop testing system according to claim 1, characterized in that, During the configuration phase, the virtualization hardware adaptation layer performs the following actions: Step 1: In the virtualization hardware adaptation layer configuration interface, map the signal points from the "CAN database" to the "Ethernet" service description file in a graphical way; Step 2: The protocol mapper establishes signal conversion rules based on the configuration information; Step 3: The FPGA configuration generator compiles the mapping rules into hardware-executable logic code; Step 4: The compiled configuration is loaded into the FPGA programmable logic, completing the hardware reconfiguration.

7. The battery management system hardware-in-the-loop testing system according to claim 1, characterized in that, During the test execution phase, the actions performed by the virtualization hardware adaptation layer include: When the signal flow is in the forward direction: the upper-layer test software generates the original current excitation signal; the signal abstraction engine receives the original excitation signal and standardizes it into a standardized signal of a unified format; the protocol mapper converts the standardized signal into the target protocol format - Ethernet protocol data packet according to preset rules; the FPGA executes protocol stack processing to generate physical signals that conform to the physical layer specifications; and sends the physical signals to the battery management system under test through the Ethernet port.

8. The battery management system hardware-in-the-loop testing system according to claim 1, characterized in that, During the test execution phase, the actions performed by the virtualization hardware adaptation layer include: When the signal flow is reversed: the response signal of the battery management system under test returns a physical signal through the physical port; the FPGA receives the physical signal and initially parses it into the target protocol format - Ethernet protocol data packet; the signal abstraction engine restores the target protocol format - Ethernet protocol data packet into a standardized signal of the unified format; the standardized signal is returned to the upper-layer test software for further processing.

9. A hardware-in-the-loop testing method for a battery management system, characterized in that, Based on the battery management system hardware-in-the-loop testing system according to any one of claims 1-8, the method includes: Input user testing requirements, which include multiple test parameters; The intelligent test case generation engine generates test case sets based on user testing requirements using a combined testing algorithm module and a reinforcement learning agent module. The dynamic model scheduler determines the testing phase based on user testing needs and dynamically switches battery models. The parallelization controller receives the test case set from the intelligent test case generation engine, and uses containerization technology to intelligently parse and decompose the test case set into multiple independent and resource-isolated test subtasks for parallel execution, and stores the task status and test results in a real-time database. The test executor obtains the test case scripts for each test subtask from the parallelization controller and sends stimulus signals to the virtualization hardware adaptation layer in strict accordance with the timing sequence. The virtualized hardware adaptation layer converts the excitation signal into a physical signal and sends it to the battery management system under test.

10. The battery management system hardware-in-the-loop testing method according to claim 9, characterized in that, Also includes: The response signals from the battery management system under test are uploaded to the real-time database through the virtualization hardware adaptation layer for analysis by the intelligent use case generation engine.

Images