Hardware-in-the-loop test method of battery management system and related equipment

Abstract

The invention discloses a hardware-in-the-loop test method of a battery management system and related equipment, and relates to the technical field of battery management systems, the method comprises the steps that hardware interface parameters and electrical characteristic parameters of a to-be-tested battery management system are acquired, and the electrical characteristic parameters comprise a target voltage platform; determining a universal hardware resource and a redundant interface strategy of the hardware-in-the-loop test bench based on a preset reference voltage platform and a target voltage platform; based on the redundant interface strategy and the hardware interface parameters, generating an interface mapping rule of a switching wire harness of the hardware-in-the-loop test bench; based on an interface mapping rule, connecting a signal conditioning module of the hardware-in-the-loop test bench with the battery management system to be tested through a switching wire harness; generating a simulation execution instruction set in a real-time simulation machine of the hardware-in-the-loop test bench based on the electrical characteristic parameters; and based on the simulation execution instruction set, controlling the real-time simulation machine to perform signal simulation and fault injection test, and outputting a simulation test result.

Description

Technical Field

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

[0002] Currently, hardware-in-the-loop (HIL) testing of battery management systems (BMS) for electric vehicles faces significant challenges. OEMs typically need to adapt to BMS hardware from multiple battery pack suppliers, and the hardware from different suppliers varies significantly in terms of interface definitions, voltage platforms (e.g., 400V or 800V), cell count, and communication protocols. Traditional HIL test benches are usually custom-developed for a single BMS hardware platform, requiring the repeated construction of a dedicated test environment for each new supplier or voltage platform. This not only wastes hardware resources but also significantly increases development costs and time investment.

[0003] In scenarios with limited testing resources, existing solutions cannot adapt to diverse BMS hardware environments. For example, the electrical characteristics of high-voltage interfaces (such as total voltage sampling and insulation detection) vary with the voltage platform, while general-purpose signal interfaces (such as temperature acquisition and communication buses), although functionally identical, require independent configuration due to differences in electrical specifications. This fragmented compatibility design leads to poor test bench scalability, complex maintenance, and frequent hardware modifications that can introduce connection reliability risks, ultimately affecting the comprehensiveness of BMS software verification and development progress. Therefore, a hardware-in-the-loop testing method for battery management systems is urgently needed to address the aforementioned technical problems. Summary of the Invention

[0004] The summary section introduces a series of simplified concepts, which will be further explained in detail in the detailed description section. This summary section is not intended to limit the key and essential technical features of the claimed technical solutions, nor is it intended to define the scope of protection of the claimed technical solutions.

[0005] In a first aspect, this application provides a hardware-in-the-loop testing method for a battery management system, including: Obtain the hardware interface parameters and electrical characteristic parameters of the battery management system under test, wherein the electrical characteristic parameters include the target voltage platform; Based on the preset reference voltage platform and the target voltage platform, the general hardware resources and redundancy interface strategy of the hardware-in-the-loop test bench are determined. Based on the redundant interface strategy and the hardware interface parameters, the interface mapping rules for the adapter harness of the hardware-in-the-loop test bench are generated. Based on the interface mapping rules, the signal conditioning module of the hardware-in-the-loop test bench and the battery management system under test are connected through the adapter harness. Based on the electrical characteristic parameters, a set of simulation execution instructions is generated in the real-time simulator of the hardware-in-the-loop test bench; Based on the simulation execution instruction set, the real-time simulator is controlled to perform signal simulation and fault injection tests, and the simulation test results are output.

[0006] In some implementations, determining the general hardware resources and redundancy interface strategy of the hardware-in-the-loop test bench based on the preset reference voltage platform and the target voltage platform includes: Based on the preset reference voltage platform, the general hardware channel type and number of channels of the hardware-in-the-loop test bench are determined; An electrical compatibility analysis is performed on the target voltage platform and the preset reference voltage platform to determine the unified electrical specifications of the functionally equivalent signal interface. The functionally equivalent signal interface refers to the interface that performs the same signal function in the preset reference voltage platform and the target voltage platform. Based on the voltage range characteristics of the target voltage platform, determine the redundancy resource configuration strategy for the target voltage interface corresponding to the target voltage platform; Based on the aforementioned redundant resource configuration strategy, a physically isolated architecture is constructed; Based on the general hardware channel type, the number of channels, the unified electrical specifications, and the physical isolation architecture, the general hardware resources and redundancy interface strategy of the hardware-in-the-loop test bench are determined.

[0007] In some implementations, generating the interface mapping rules for the adapter harness of the hardware-in-the-loop test bench based on the redundant interface strategy and the hardware interface parameters includes: Based on the aforementioned redundant interface strategy, the reference voltage resource interface group and the target voltage resource interface group at the output of the signal conditioning module are determined. Based on the hardware interface parameters, the physical interface pin information of the battery management system under test is analyzed. Based on the electrical compatibility of the physical interface pin information with the reference voltage resource interface group and the target voltage resource interface group, the signal mapping relationship is determined. Based on the signal mapping relationship, an interface mapping rule for the adapter harness is generated, wherein the interface mapping rule is the pin connection logic between the output of the signal conditioning module and the physical interface of the battery management system under test.

[0008] In some implementations, the step of connecting the signal conditioning module of the hardware-in-the-loop test bench and the battery management system under test via the adapter harness based on the interface mapping rules includes: Based on the interface mapping rules, the pin connection logic of the adapter harness is determined; Based on the pin connection logic, the output interface of the signal conditioning module is physically connected to the physical interface of the battery management system under test.

[0009] In some implementations, the electrical characteristic parameters include a target voltage platform, cell quantity parameters, and communication protocol type. The step of generating a simulation execution instruction set for the real-time simulator of the hardware-in-the-loop test bench based on the electrical characteristic parameters includes: Based on the cell quantity parameters, determine the number of individual voltage channels in the cell simulator; Based on the target voltage platform, determine the total voltage output range of the constant voltage source; Based on the communication protocol type, determine the protocol error mode library for the bus fault injection channel; The simulation execution instruction set is generated based on the number of individual voltage channels, the total voltage output range, and the protocol error mode library.

[0010] In some implementations, controlling the real-time simulator to perform signal simulation and fault injection tests based on the simulation execution instruction set, and outputting simulation test results, includes: Based on the number of voltage channels in a single cell, the cell simulator is controlled to output a programmable voltage sequence that matches the cell quantity parameter; Based on the total voltage output range, the constant voltage source is controlled to output a DC voltage signal corresponding to the target voltage platform; Based on the protocol error mode library, the bus fault injection channel is controlled to perform preset communication protocol error injection operations; Collect the response messages of the battery management system under test to the programmable voltage sequence, the DC voltage signal, and the protocol error injection operation; Based on preset security judgment rules, the response message is verified to generate the simulation test results.

[0011] Secondly, this application proposes a hardware-in-the-loop testing device for a battery management system, comprising: The parameter acquisition unit is used to acquire the hardware interface parameters and electrical characteristic parameters of the battery management system under test, wherein the electrical characteristic parameters include the target voltage platform; The resource determination unit is used to determine the general hardware resources and redundancy interface strategy of the hardware-in-the-loop test bench based on the preset reference voltage platform and the target voltage platform. The rule generation unit is used to generate interface mapping rules for the adapter harness of the hardware-in-the-loop test bench based on the redundant interface strategy and the hardware interface parameters. A hardware connection unit is used to connect the signal conditioning module of the hardware-in-the-loop test bench and the battery management system under test through the adapter harness, based on the interface mapping rules. The instruction generation unit is used to generate a set of simulation execution instructions in the real-time simulator of the hardware-in-the-loop test bench based on the electrical characteristic parameters. The simulation test unit is used to control the real-time simulator to perform signal simulation and fault injection tests based on the simulation execution instruction set, and output the simulation test results.

[0012] Thirdly, an electronic device includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program stored in the memory to implement the hardware-in-the-loop testing method for the battery management system of any one of the first aspects.

[0013] Fourthly, this application proposes a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps of the hardware-in-the-loop testing method for the battery management system of any one of the first aspects.

[0014] Fifthly, this application proposes a computer program product, including a computer program, which, when executed by a processor, implements the steps of the hardware-in-the-loop testing method for the battery management system of any one of the first aspects.

[0015] In summary, the hardware-in-the-loop testing method for battery management systems provided in this application achieves hardware compatibility of the test bench under multiple voltage platforms (such as 400V or 800V) by dynamically identifying the functional equivalent signal interface and dedicated high-voltage interface through a preset reference voltage platform, and configuring general hardware resources and physical isolation architecture based on redundancy strategies. Furthermore, it generates the physical connection logic of the adapter harness through interface mapping rules, enabling the signal conditioning module to quickly adapt to the physical interfaces of different BMSs, significantly reducing the cost of bench modification due to hardware differences. Combined with the dynamic generation of simulation instruction sets based on electrical characteristic parameters, it ensures the complete execution of signal simulation and fault injection testing. This application unifies the testing process for multiple BMS hardware environments, improves bench reusability and shortens test switching time, while ensuring test coverage and result reliability, providing an efficient and low-cost verification foundation for the iterative development of BMS software. Attached Figure Description

[0016] Various other advantages and benefits will become apparent to those skilled in the art upon reading the following detailed description of preferred embodiments. The accompanying drawings are for illustrative purposes only and are not intended to limit this specification. Furthermore, the same reference numerals denote the same parts throughout the drawings. In the drawings: Figure 1 This is a schematic flowchart of a hardware-in-the-loop testing method for a battery management system provided in an embodiment of this application; Figure 2 This is a schematic diagram of a hardware-in-the-loop testing device for a battery management system provided in an embodiment of this application; Figure 3 This is a schematic diagram of a hardware-in-the-loop test electronic device for a battery management system, provided as an embodiment of this application. Detailed Implementation

[0017] The terms "first," "second," "third," "fourth," etc. (if present) 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 described herein can be implemented in a sequence other than that 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. The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them.

[0018] Please see Figure 1 This is a schematic flowchart of a hardware-in-the-loop testing method for a battery management system provided in an embodiment of this application, which may specifically include: S110. Obtain the hardware interface parameters and electrical characteristic parameters of the battery management system under test, wherein the electrical characteristic parameters include the target voltage platform; For example, in the initial stage of hardware-in-the-loop testing, it is necessary to analyze the physical characteristics and electrical specifications of the battery management system (BMS) under test. Hardware interface parameters include the physical connection definition between the BMS and the external environment, including connector type, pin count, and functional allocation (such as high-voltage sampling pins, communication bus interfaces, and low-voltage control signal terminals). Essentially, these describe the mechanical adaptation rules between the BMS and the test bench. Electrical characteristic parameters define the system-level electrical behavior. The core parameter is the target voltage platform (e.g., 400V), which directly affects the amplitude range and safety isolation requirements of high-voltage signals (total voltage acquisition, insulation detection). Furthermore, the cell count parameter determines the channel size for single-cell voltage simulation, while the communication protocol type (e.g., CAN or CANFD) constrains the syntax rules for bus fault injection. The synergistic effect of these parameters provides physical and electrical layer input constraints for subsequent general hardware resource configuration, interface mapping rule generation, and test instruction set construction, serving as the data foundation for ensuring test compatibility and safety.

[0019] S120. Based on the preset reference voltage platform and target voltage platform, determine the general hardware resources and redundancy interface strategy of the hardware-in-the-loop test bench. For example, a preset reference voltage platform (e.g., 800V) is used as the benchmark for hardware resource planning. By comparing the electrical compatibility characteristics of the target voltage platform (e.g., 400V), the test bench resources are adapted. For functionally equivalent signal interfaces (e.g., temperature acquisition, communication bus, low-voltage control, and other general signals unrelated to voltage amplitude), their level range, filtering parameters, and other electrical specifications are unified based on the dual-platform electrical compatibility analysis results, ensuring that general hardware channels (e.g., multi-channel resistor simulation channels, digital I / O channels) can be directly reused. For voltage-dependent interfaces (e.g., total voltage sampling, insulation detection, and other high-voltage interfaces dependent on voltage platform values), redundant hardware resources (e.g., independent high-voltage source modules) are configured according to the amplitude range characteristics of the target voltage platform, and a physical isolation architecture is constructed to separate electrical circuits of different voltage levels. Finally, by combining the general hardware channel types and quantities, unified electrical specifications, and redundant resource isolation architecture, a resource allocation strategy that balances compatibility and safety is generated, providing hardware-level constraints for subsequent interface mapping.

[0020] S130. Based on the redundancy interface strategy and hardware interface parameters, generate the interface mapping rules for the adapter bundle of the hardware-in-the-loop test bench. For example, based on the redundancy interface strategy analysis, the signal conditioning module output terminals are grouped (reference voltage resource interface group and target voltage resource interface group). Combined with the physical pin definitions in the BMS hardware interface parameters under test, a signal mapping relationship is established through electrical compatibility matching. Specifically, firstly, based on the interface group structure divided by the redundancy strategy (such as high-voltage or low-voltage isolation channel groups), candidate resource interfaces compatible with the electrical characteristics of the BMS pins are screened. Then, according to the pin function type (such as total voltage sampling, insulation detection, communication bus, etc.) and signal direction (input or output), the BMS physical pins and benchtop resource interfaces are mapped one-to-one according to level range, impedance characteristics, and isolation requirements, eliminating combinations with mismatched electrical parameters (e.g., avoiding mismapping an 800V withstand voltage interface to a 400V resource channel). Finally, based on the mapping relationship, the pin connection logic of the adapter bundle is generated, clarifying the physical connection rules between each interface of the signal conditioning module output terminal and the BMS connector pins, achieving a standardized definition of the hardware topology. This process automatically completes electrical compatibility verification and logical binding through algorithms, avoiding the risk of mismatch caused by manual intervention and providing an interface configuration basis for subsequent physical connections.

[0021] S140. Based on interface mapping rules, the signal conditioning module of the hardware-in-the-loop test bench and the battery management system under test are connected via adapter harness. For example, the pin connection logic generated based on interface mapping rules drives the physical assembly process of the adapter harness, achieving an electrically isolated connection between the signal conditioning module and the battery management system under test (BMS). The adapter harness serves as a standardized interface adapter carrier, with its internal wires routed according to the pin correspondence defined by the mapping rules (e.g., the "total voltage sampling output terminal 1" of the signal conditioning module connects to the "high voltage positive pin" of the BMS connector). Simultaneously, based on the physical isolation architecture in the redundant interface strategy, the signal conditioning module separates high-voltage resource groups (e.g., 800V withstand voltage lines) from low-voltage resource groups (e.g., 12V control signal lines) within the adapter harness, achieving electrical isolation through independent shielding layers and insulating materials. This connection process ensures safe isolation of signals at different voltage levels during transmission, and the adapter harness interface matches the physical connector specifications of the BMS under test, forming a standardized topology link between the signal conditioning module, the adapter harness, and the BMS. This link enables the simulated signals output from the test bench (such as programmable voltage sequences and fault injection commands) to be level-converted and noise-filtered before being input into the hardware interface with electrical characteristics compatible with the target BMS. At the same time, it safely transmits the BMS response signal back to the test bench, providing a physical layer path for multi-dimensional testing.

[0022] S150. Based on electrical characteristic parameters, generate a set of simulation execution instructions for the real-time simulator of the hardware-in-the-loop test bench; For example, the cell quantity parameter, target voltage platform, and communication protocol type in the electrical characteristic parameters jointly drive the automated construction of the simulation execution instruction set. First, the cell quantity parameter is directly mapped to the number of single-cell voltage channels that the cell simulator needs to activate, ensuring that the voltage sequence output scale is consistent with the physical structure of the battery pack. Second, the target voltage platform constrains the total voltage output range of the constant voltage source, making the simulated total voltage signal match the electrical platform characteristics of the system under test. At the same time, the communication protocol type (such as CAN or CANFD) calls a pre-set protocol rule library to extract the syntax error patterns and abnormal frame formats of the corresponding bus fault injection channels. These three types of hardware resource parameters are integrated by the real-time simulator scheduling algorithm to form an instruction sequence set containing channel configuration instructions, voltage output instructions, and fault injection logic, providing an executable low-level control sequence for subsequent signal simulation and fault testing.

[0023] S160: Based on the simulation execution instruction set, control the real-time simulator to perform signal simulation and fault injection tests, and output the simulation test results.

[0024] For example, the real-time simulator, based on the simulation execution instruction set, synchronously schedules hardware resources such as the cell simulator, constant voltage source, and bus fault injection channel to achieve multi-dimensional signal collaborative simulation and active fault injection. Specifically, the cell simulator outputs a programmable voltage waveform simulating the dynamic characteristics of the battery pack according to the number and sequence parameters of the individual cell voltage channels defined in the instruction set; the constant voltage source generates a high-precision DC total voltage signal according to the amplitude range of the target voltage platform to reproduce the real high-voltage environment; the bus fault injection channel injects preset communication anomalies (such as CAN error frames and signal delays) based on the protocol error mode library to verify the communication fault tolerance mechanism. At the same time, the response messages of the BMS under test to the simulation signals and fault operations are collected in real time, and multi-level verification of response timing, logic compliance, and parameter thresholds is performed through preset safety judgment rules. Finally, the simulation test results include fault mode classification, safety mechanism effectiveness, and performance compliance status.

[0025] In summary, this application's embodiments improve the adaptability of hardware-in-the-loop test benches to multi-supplier, multi-voltage platform battery management systems by constructing a compatible system centered on a preset reference voltage platform. Specifically, based on compatibility analysis between the target voltage platform and the reference platform, functionally equivalent signal interfaces and voltage-sensitive interfaces are divided. Universal hardware resources are reused through unified electrical specifications. Simultaneously, a redundancy strategy is used to configure isolated hardware resource groups for high-voltage sensitive interfaces, avoiding bench reconfiguration caused by voltage platform switching. Furthermore, interface mapping rules for adapter bundles are generated based on hardware interface parameters, transforming the electrical characteristic matching between the signal conditioning module output and the physical interface of the system under test into standardized pin connection logic. Hardware-level adaptation can be completed simply by replacing the adapter bundle, reducing connection modification costs and mismatch risks. Simultaneously, based on electrical characteristic parameters such as cell quantity, voltage platform, and communication protocol, a simulation execution instruction set for driving cell simulators, constant voltage sources, and bus fault injection channels is generated, enabling automated test execution of battery cell voltage sequence simulation, high-voltage environment simulation, and communication protocol error injection. The embodiments of this application enable a single test bench to be compatible with diverse BMS hardware with different voltage platforms, interface specifications, and communication protocols. While ensuring test coverage and security, it provides an efficient and low-cost verification foundation for BMS software iteration in a multi-vendor collaborative development model, shortens the test switching cycle in a multi-vendor hardware environment, and improves the reusability of hardware-in-the-loop test benches.

[0026] In some instances, based on a preset reference voltage platform and a target voltage platform, the general hardware resources and redundancy interface strategies for the hardware-in-the-loop test bench are determined, including: Based on a preset reference voltage platform, the general hardware channel type and number of channels for the hardware-in-the-loop test bench are determined. An electrical compatibility analysis is performed on the target voltage platform and the preset reference voltage platform to determine the unified electrical specifications of the functionally equivalent signal interface. The functionally equivalent signal interface refers to the interface that performs the same signal function in both the preset reference voltage platform and the target voltage platform. Based on the voltage range characteristics of the target voltage platform, determine the redundancy resource configuration strategy for the target voltage interface corresponding to the target voltage platform; A physically isolated architecture is constructed based on a redundant resource configuration strategy; Based on the common hardware channel type, number of channels, unified electrical specifications, and physical isolation architecture, the common hardware resources and redundancy interface strategy of the hardware-in-the-loop test bench are determined.

[0027] For example, using a preset reference voltage platform (e.g., 800V) as the benchmark for hardware resource configuration, the general hardware channel types and their quantities for the hardware-in-the-loop test bench are determined based on the typical testing requirements of this platform. General hardware channel types include, but are not limited to: battery cell voltage simulation channels (e.g., 200 channels), temperature simulation channels (e.g., 60 resistance simulation channels), fault injection channels (e.g., 60 channels), high-voltage relay simulation channels (e.g., 8 channels), and bus simulation channels (e.g., 6 CAN or CANFD channels). The channel quantity setting must cover the testing requirements of the largest battery pack (e.g., 200 series-connected cells) under the reference voltage platform and complex fault injection scenarios, ensuring that the general hardware resources have basic compatibility capabilities.

[0028] Electrical compatibility analysis is performed on the target voltage platform (e.g., 400V) and the preset reference voltage platform (800V) to identify interfaces performing the same signal functions in both platforms, defining them as functionally equivalent signal interfaces. These interfaces include temperature acquisition interfaces (NTC or PTC thermistor simulation), communication bus interfaces (CAN or CANFD), and low-voltage control signal interfaces (digital I / O, PWM). Analysis confirms that the electrical behavior of these interfaces (e.g., voltage range, impedance characteristics, signal type) is compatible across both platforms, leading to the development of standardized electrical specifications. For example, temperature signal interfaces are standardized to a 0-5V voltage output range; communication bus interfaces to a 500kbps baud rate and ±2V differential voltage; and digital control signal interfaces to a 12V or 24V drive level and a 10mA load capacity. This step ensures that general-purpose hardware channels (e.g., resistor simulation channels, digital I / O channels) can be adapted to equivalent signal interfaces of different voltage platforms without modification, achieving resource reuse.

[0029] For high-voltage sensitive interfaces (such as total voltage sampling and insulation detection interfaces) in the target voltage platform that are strongly correlated with voltage amplitude, a redundancy resource configuration strategy needs to be formulated based on their voltage range characteristics. When the target voltage platform is 400V, the range (0-600V) of its total voltage sampling interface is lower than the range (0-1000V) of the preset reference voltage platform of 800V. Therefore, a step-down high-voltage source module with a 0-600V output range needs to be independently configured for the 400V platform. Similarly, due to the difference in insulation resistance threshold of the low-voltage platform, the insulation detection interface needs to be configured with a dedicated insulation resistance simulation card with a range of 0-500kΩ. In addition, for the fault modes unique to the low-voltage platform (such as specific short-circuit current thresholds), a dedicated redundant channel needs to be reserved in the fault injection channel. All redundant resources must maintain physical independence from the reference platform resources to ensure that there are no conflicts in electrical parameters.

[0030] The redundant resource configuration strategy based on high-voltage sensitive interfaces requires the construction of a physical isolation architecture to achieve a hard separation of high- and low-voltage electrical circuits. This architecture allocates resource groups for the preset reference voltage platform (such as an 800V high-voltage source and a 0-1000V insulation detection module) and redundant resource groups for the target voltage platform (such as a 400V high-voltage source and a 0-500kΩ insulation detection card) to independent hardware areas. Electrical isolation zones are defined via a backplane bus, and independent power supplies and grounding circuits are configured for the redundant resource groups. Physically separated interface groups are set at the output of the signal conditioning module: the reference voltage resource interface group connects to 800V compatible resources, and the target voltage resource interface group connects to 400V redundant resources. The isolation architecture uses shielding layers and insulating materials to block crosstalk between high and low voltage signals, ensuring operational safety and signal integrity.

[0031] By integrating the types and quantities of general-purpose hardware channels, the unified electrical specifications of functionally equivalent interfaces, the redundant resource configuration of high-voltage sensitive interfaces, and the physical isolation architecture, a complete general-purpose hardware resource and redundant interface strategy is generated. This strategy allows for the direct reuse of general-purpose hardware resources (such as 200 cell simulation channels and 60 temperature simulation channels) while adhering to unified electrical specifications; functionally equivalent signal interfaces (temperature acquisition, communication bus, etc.) are connected to the signal conditioning module according to standardized parameters; and dedicated high-voltage interfaces are switched to the corresponding redundant resource group through a physical isolation architecture (e.g., the 400V total voltage sampling signal is routed only to the target voltage resource interface group). The final strategy is written into the hardware-in-the-loop test bench's control system configuration file, serving as a hardware-layer constraint for subsequent interface mapping and test execution.

[0032] In summary, this application's embodiments achieve test bench resource adaptation by integrating the hardware compatibility requirements of multiple voltage platforms. Functionally equivalent interfaces and high-voltage sensitive interfaces are divided based on a preset reference voltage platform. The former reuses general-purpose hardware resources through unified electrical specifications, while the latter configures isolated dedicated resources through redundancy strategies, supplemented by a physical isolation architecture to ensure the safe parallel operation of high and low voltage signals. This method reduces the cost of test bench modifications caused by voltage platform switching and avoids redundant investment in hardware resources. Simultaneously, the standardized resource strategy provides clear electrical and topological constraints for the mapping of transfer harness interfaces, ensuring the reliability and testing efficiency of multi-BMS hardware connections, ultimately improving the reusability and adaptability of the test bench in multi-vendor collaborative environments.

[0033] In some instances, interface mapping rules for the adapter harnesses of a hardware-in-the-loop test bench are generated based on redundancy interface strategies and hardware interface parameters, including: Based on the redundancy interface strategy, the reference voltage resource interface group and the target voltage resource interface group at the output of the signal conditioning module are determined. Based on the hardware interface parameters, the physical interface pin information of the battery management system under test is analyzed. Based on the electrical compatibility of the physical interface pin information with the reference voltage resource interface group and the target voltage resource interface group, the signal mapping relationship is determined. Based on the signal mapping relationship, the interface mapping rules of the adapter harness are generated. The interface mapping rules are the pin connection logic between the output of the signal conditioning module and the physical interface of the battery management system under test.

[0034] For example, based on the physical isolation architecture built in the redundant interface strategy, the output of the signal conditioning module is divided into two independent reference voltage resource interface groups and target voltage resource interface groups. The reference voltage resource interface group connects to the dedicated hardware resources of the preset reference voltage platform (e.g., 800V), including high-voltage channels strongly related to the high-voltage platform, such as a high-voltage direct-flow controlled voltage source (output range 0-1000V) and an insulation control module (insulation resistance simulation range 0-1000kΩ). The target voltage resource interface group connects to the redundant hardware resources configured for the target voltage platform (e.g., 400V), including isolated resource groups such as a step-down high-voltage source (output range 0-600V) and a range-adaptive insulation detection card (range 0-500kΩ). The division of the interface groups follows the electrical separation principle of the physical isolation architecture, isolating high and low voltage loops through the backplane bus to ensure that the reference resource group and the target resource group are not electrically coupled, providing a safe topology basis for subsequent pin mapping.

[0035] The physical interface pin definition information of the battery management system under test (BMS) is extracted based on hardware interface parameters. This includes pin function type, electrical parameters, and mechanical specifications. Pin function type must distinguish between high-voltage sensitive pins (e.g., positive or negative for total voltage sampling, positive or negative for insulation detection) and functionally equivalent signal pins (e.g., temperature acquisition, CAN bus, digital I / O). Electrical parameters include the rated voltage range of each pin (e.g., the total voltage sampling pin supports 0-1000V), impedance characteristics (e.g., the high impedance input requirement for the insulation detection pin), signal direction (input or output), and isolation level. Mechanical specifications record the connector model, pin arrangement, and anti-misfit structure. This parsing process is completed by an automated script matching a pre-set BMS hardware database, generating a structured pin information table to clarify the electrical constraints of the object to be connected.

[0036] The parsed pin information is electrically compatible with the output interface group of the signal conditioning module. Functionally equivalent signal pins (such as temperature acquisition pins) are uniformly mapped to general hardware resource channels. For example, the BMS's NTC thermistor interface is mapped to the resistance simulation channel of the signal conditioning module and a unified electrical specification (0-5V output range) is applied. CAN bus pins are mapped to bus simulation channels and follow the preset 500kbps baud rate and ±2V differential level specification. High-voltage sensitive pins are routed to the corresponding resource group according to the voltage platform. For example, when the target voltage platform is 400V, its total voltage sampling pin is mapped to the step-down high-voltage source (0-600V output) of the target voltage resource interface group, and the insulation detection pin is mapped to a dedicated insulation resistance simulation card (0-500kΩ range). Compatibility verification requires eliminating conflicting combinations of electrical parameters (such as avoiding mismapping of 800V withstand voltage requirement pins to 400V resource groups) and ensuring signal direction matching (such as output pins being connected only to BMS input pins). Finally, a signal mapping table is generated that clearly defines the one-to-one correspondence between each BMS pin and the signal conditioning module interface.

[0037] The physical connection logic of the adapter harness is generated based on the signal mapping table. The pin connection logic defines the correspondence between the two ends of the adapter harness. For standard interfaces, pin numbers are defined according to the physical order of the signal conditioning module output interface group (reference or target resource group). Custom interfaces completely replicate the pin arrangement of the BMS connector under test. Internal wiring rules require that functionally equivalent signals use general-purpose shielded twisted-pair cable, high-voltage sensitive signals use independent shielding layers and reinforced insulated wires, and high- and low-voltage lines are separately wired within the adapter harness; mechanical interfaces must be compatible with BMS connector specifications. The final output includes an interface mapping rule document containing pin correspondence tables, wire gauge specifications, and isolation requirements, driving the customized production of the adapter harness.

[0038] In summary, this application's embodiments, through redundant interface strategies and collaborative analysis of hardware interface parameters, transform the standardized output terminals of the signal conditioning module and diverse BMS physical interfaces into explicit pin connection logic. Based on electrical compatibility, high-voltage sensitive signals are dynamically routed to isolated resource groups, while simultaneously unifying the electrical specifications of functionally equivalent signals, ensuring that the transfer harness achieves plug-and-play physical adaptation while meeting the safety isolation requirements of multi-voltage platforms. This application's embodiments replace manual wiring modifications with standardized mapping rules, avoiding signal crosstalk or equipment damage caused by misconfiguration, reducing the connection modification costs and operational risks of multi-BMS hardware switching, and providing a physical layer link foundation for hardware-in-the-loop testing.

[0039] In some instances, based on interface mapping rules, the signal conditioning module of the hardware-in-the-loop test bench and the battery management system under test are connected via adapter harnesses, including: Based on the interface mapping rules, determine the pin connection logic of the adapter harness; Based on pin connection logic, the output interface of the signal conditioning module is physically connected to the physical interface of the battery management system under test.

[0040] For example, the pin connection logic generated based on interface mapping rules guides the physical assembly process of the adapter harness, enabling a secure connection between the signal conditioning module and the battery management system under test (BSD). The pin connection logic defines the correspondence between the output interfaces of the signal conditioning module (including the reference voltage resource interface group and the target voltage resource interface group) and the physical interfaces of the BSD. Specifically, the adapter harness includes standardized interface terminals and custom interface terminals. The standardized interface terminals follow the grouping structure of the signal conditioning module's output terminals (the reference voltage resource interface group corresponds to a preset reference voltage platform resource, and the target voltage resource interface group corresponds to a redundantly configured target voltage platform resource), and their pin numbers are consistent with the physical order of the signal conditioning module interfaces. The custom interface terminals completely replicate the pin arrangement order and mechanical specifications (such as anti-misinsertion keyway structure) of the BSD connectors. The internal wiring of the adapter harness is executed according to the pin connection logic. Functionally equivalent signals (such as temperature acquisition and communication bus) are transmitted uniformly using general shielded twisted pair cables. High-voltage sensitive signals (such as total voltage sampling and insulation detection) are routed to the reference or target resource interface group through independent shielding layers and reinforced insulated wires according to the physical isolation architecture requirements, ensuring that there is no electrical coupling between high and low voltage lines inside the adapter harness.

[0041] Based on pin connection logic, the physical circuit connection between the output of the signal conditioning module and the battery management system under test (BMD) is executed. During operation, first, the standardized interface of the adapter harness is inserted into the output port of the signal conditioning module; then, the custom interface is aligned and connected to the physical connector of the BMD, ensuring complete engagement of the anti-misfit structure. During the connection process, the separate shielding layer inside the adapter harness physically isolates the wires of the reference voltage resource interface group (e.g., connecting to an 800V high-voltage source) from the target voltage resource interface group (e.g., connecting to a 400V redundant high-voltage source), blocking crosstalk paths between high and low voltage signals. Simultaneously, all high-voltage sensitive signal lines are subjected to double insulation protection, and their withstand voltage rating (e.g., 1500V withstand voltage insulation layer for 800V lines) matches the electrical safety requirements of the target platform. This physical connection forms a standardized topology link from the signal conditioning module through the adapter harness to the battery management system. This allows simulation signals (such as programmable voltage sequences output by the cell simulator) and fault injection commands to be input into the hardware interface of the system under test after level conversion and noise filtering, in accordance with the electrical characteristics of the system under test. At the same time, the response signals of the battery management system are safely transmitted back to the test bench.

[0042] In summary, this application embodiment improves the compatibility efficiency and safety of hardware-in-the-loop test benches with diverse battery management system interfaces through standardized physical connections driven by pin connection logic. The adapter harness matches the signal conditioning module output with the physical interface of the system under test based on interface mapping rules. Only the harness needs to be replaced to complete the hardware-level switching for different voltage platforms (e.g., 400V or 800V) and interface specifications, avoiding structural modifications to the test bench. High and low voltage signals are rigidly isolated within the adapter harness through independent shielding layers and enhanced insulation, eliminating the risk of electrical crosstalk caused by voltage platform differences and ensuring operational safety during testing. Simultaneously, a mechanical anti-misfit design prevents physical mismatches during connection, ensuring reliable signal transmission. This application embodiment minimizes the cost of connecting and modifying multi-BMS hardware environments and shortens test switching time, providing a physical layer foundation for testing and verification in multi-vendor collaborative development models.

[0043] In some instances, electrical characteristic parameters include the target voltage platform, cell quantity parameters, and communication protocol type. Based on these electrical characteristic parameters, a set of simulation execution instructions is generated for the real-time simulator of the hardware-in-the-loop test bench, including: Based on the cell quantity parameter, determine the number of individual voltage channels in the cell simulator; Based on the target voltage platform, determine the total voltage output range of the constant voltage source; Based on the communication protocol type, determine the protocol error mode library for the bus fault injection channel; Based on the number of individual voltage channels, the total voltage output range, and the protocol error mode library, a simulation execution instruction set is generated.

[0044] For example, the cell quantity parameter in the electrical characteristic parameters determines the number of single-cell voltage channels that the cell simulator needs to activate. Specifically, the real-time simulator parses the cell quantity parameter (e.g., 200 cells in series) and maps it to channel activation instructions for the cell simulator, ensuring that the number of channels strictly matches the physical structure of the battery pack. For instance, when the number of cells is 200, the simulator automatically configures 200 single-cell voltage simulation channels and assigns independent voltage programming addresses; if the number of cells is 100, only the first 100 channels are activated, and the remaining channels are put into a dormant state. This process is automatically completed by the channel management algorithm of the real-time simulator, ensuring that the scale of the output voltage sequence is consistent with the battery topology of the BMS under test, providing a hardware resource adaptation basis for single-cell voltage simulation.

[0045] The target voltage platform parameters constrain the total voltage output range of the constant voltage source. The real-time simulator calculates the required DC voltage signal amplitude range to be output by the constant voltage source based on the target voltage platform (e.g., 400V or 800V) and safety margin requirements. For example, for a 400V platform, the output range is set to 0-600V to cover full-scale and overvoltage testing scenarios; for an 800V platform, the output range is extended to 0-1000V. Simultaneously, combined with the hardware resources configured in the redundant interface strategy (e.g., a step-down high-voltage source module), constant voltage source control commands are generated, specifying the target voltage resource interface group (400V platform) or the reference voltage resource interface group (800V platform) as the output path, ensuring that the total voltage signal is compatible with the platform's electrical characteristics and routed to the correct physical isolation channel.

[0046] The communication protocol type parameter drives the invocation of the protocol error mode library for the bus fault injection channel. The real-time emulator retrieves a pre-built protocol rule library based on the protocol type (e.g., CAN or CANFD) and extracts the corresponding syntax error patterns and exception frame formats. For example, the CAN protocol error mode library includes syntax rules for error frame injection, bit stuffing violations, and CRC checksum errors; the CANFD protocol additionally supports message delay and length error injection at variable rates. The protocol error mode library provides executable exception logic templates for the fault injection channel, including error triggering conditions (e.g., triggering with a specific ID message) and fault duration parameters. This process dynamically generates fault injection instructions through the protocol parsing engine, ensuring protocol compliance and scenario coverage for bus exception simulation.

[0047] By integrating three types of parameters—the number of individual voltage channels, the total voltage output range, and the protocol error mode library—the real-time simulator generates a structured simulation execution instruction set through a resource scheduling algorithm. This instruction set includes three types of instructions: channel configuration instructions: activating a specified number of individual voltage channels according to the cell quantity parameter and loading an initial voltage sequence (e.g., simulating voltage distribution under different SoC states); voltage output instructions: setting the target output voltage value of the constant voltage source (e.g., outputting 450V to simulate charging conditions on a 400V platform), the rise or fall slope, and the steady-state hold time; and fault injection logic: selecting the target fault type (e.g., CAN CRC error) based on the protocol error mode library, defining the injection time point (e.g., triggering when the bus load rate is 70%), and the duration. All instructions are sorted along a timeline and compiled into a binary control sequence executable by the real-time simulator, ensuring the coordinated operation of the cell simulator, the constant voltage source, and the bus fault injection channels.

[0048] This application's embodiments improve the accuracy and efficiency of hardware-in-the-loop testing by automating the construction of simulation execution instruction sets driven by electrical characteristic parameters. First, a strict mapping between the cell quantity parameter and the number of voltage channels per cell ensures that the voltage sequence simulation scale is consistent with the actual battery pack structure, avoiding test distortion caused by channel redundancy or insufficiency. Second, the target voltage platform dynamically constrains the output range of the constant voltage source, ensuring the electrical safety and scenario realism of the high-voltage environment simulation. Furthermore, by combining a communication protocol type-adaptive fault mode library, accurate reproduction of communication error injection is achieved. The final generated instruction set coordinates the synchronous output of multiple hardware resources, enabling the triggering of complex test scenarios such as individual cell voltage fluctuations, total voltage step changes, and bus protocol anomalies. This improves test coverage while reducing manual configuration errors, providing a test foundation for BMS functional safety verification.

[0049] In some instances, based on the simulation execution instruction set, a real-time simulator is controlled to perform signal simulation and fault injection tests, outputting simulation test results, including: Based on the number of voltage channels in a single cell, the cell simulator outputs a programmable voltage sequence that matches the cell quantity parameter; Based on the total voltage output range, control the constant voltage source to output a DC voltage signal corresponding to the target voltage platform; Based on the protocol error mode library, the control bus fault injection channel executes preset communication protocol error injection operations; Collect response messages from the battery management system under test to programmable voltage sequences, DC voltage signals, and protocol error injection operations; Based on preset security judgment rules, the response message is verified and simulation test results are generated.

[0050] For example, the real-time simulator, based on the channel configuration instructions in the simulation execution instruction set, controls the cell simulator to activate the corresponding number of individual cell voltage channels according to the cell quantity parameters (e.g., 200 channels activated for 200 cells), and loads the initial voltage sequence parameters (including the initial voltage value of each channel, slope change rules, and dynamic fluctuation mode). This sequence simulates the individual cell voltage behavior of a real battery pack under different operating conditions (e.g., voltage gradient distribution caused by SoC changes, voltage drop caused by individual cell failure), and outputs a programmable voltage waveform matching the number of cells. The timing accuracy of the voltage sequence is guaranteed by the scheduling capability of the real-time simulator, ensuring the synchronization of voltage fluctuation scenarios (e.g., charging and discharging transients) with the BMS sampling period.

[0051] Based on the total voltage output range defined by the instruction set (e.g., 0-600V for a 400V platform, 0-1000V for an 800V platform), the real-time simulator controls the constant voltage source to output a high-precision DC voltage signal. The output process follows the rise or fall slope specified by the instruction (e.g., 100V / ms to simulate rapid load changes) and the steady-state holding time (e.g., 30s constant voltage charging). Simultaneously, according to the routing logic of the redundant interface strategy, the signal is output to the target voltage resource interface group (400V platform) or the reference voltage resource interface group (800V platform), ensuring that the high-voltage circuit is transmitted through a physically isolated architecture, avoiding cross-platform electrical crosstalk.

[0052] The real-time emulator calls the protocol error mode library (e.g., the CAN protocol library includes CRC errors and bit stuffing violations, and the CANFD library supports variable rate message delays) to control the bus fault injection channel to inject preset anomalies into the BMS under test at specified time points. Error injection operations include generating syntax violation messages (e.g., error frame ID=0xFFFFFFFF), tampering with data field check bits, or inserting signal delays (e.g., 500μs). The injection logic follows the syntax rules defined by the protocol type and applies electrical anomalies (e.g., differential level offset ±1V) through the hardware layer signal conditioning module of the fault injection channel to reproduce real bus fault scenarios.

[0053] The real-time simulator synchronously acquires the responses of the battery management system under test (BMS) to programmable voltage sequences, DC voltage signals, and protocol error injection operations. In the voltage response dimension, the sequence of individual cell voltage values ​​reported by the BMS is acquired through analog input channels to verify its sampling accuracy (e.g., voltage gradient distribution) of the cell simulator output waveform and the real-time performance of its fault diagnosis logic (e.g., overvoltage or undervoltage alarm threshold triggering). In the high-voltage control response dimension, the timing of the BMS's protective actions against the total voltage signal is recorded using digital input channels and relay status feedback loops. In the communication response dimension, CAN or CANFD message data sent by the BMS is parsed in real time to extract its fault-tolerant handling mechanism for bus protocol error injection (e.g., error counter increment status, safety state switching flags). The timestamps, data content, and electrical characteristic parameters (e.g., signal rise time) of the above response messages are all fully recorded and stored in the test database, forming a complete response dataset covering hardware interface behavior, control logic execution, and communication security strategies.

[0054] The collected response messages undergo multi-level automated verification using preset safety judgment rules. First, timing compliance is verified by comparing the BMS action delay with preset thresholds (e.g., the relay disconnect command must be triggered within 10ms after the total voltage exceeds the threshold) to determine if real-time performance meets the standard. Second, logical correctness is checked by verifying whether the diagnostic logic conforms to design specifications based on the mapping relationship between injected fault modes and expected diagnostic results (e.g., after injecting a CAN CRC error, the BMS should set a "communication verification failure" fault code). Finally, parameter threshold compliance is confirmed by calculating whether the error between the reported voltage value and the simulation baseline value is ≤ ±0.5% of the full scale, and verifying whether the calculated insulation resistance value is within the set tolerance range (e.g., ±5%). The verification results output a structured test report, including fault mode classification (e.g., "communication link abnormality" or "hardware actuator failure"), safety mechanism effectiveness score (e.g., relay action compliance 95%), and performance compliance status (e.g., voltage sampling accuracy meets the standard). Test cases that fail verification and their deviation data (e.g., excessive action delay value, missing fault code number) are also marked, providing a quantitative basis for BMS software iteration and improvement.

[0055] In summary, this application's embodiments enhance the automation and scenario coverage of hardware-in-the-loop testing through a collaborative testing mechanism driven by a simulation execution instruction set. The cell simulator outputs programmable voltage sequences based on the actual battery pack structure, reproducing scenarios of abnormal individual cell voltages; the constant voltage source outputs a platform-compatible high-voltage signal based on a physically isolated architecture, ensuring the safety of the total voltage simulation; the bus fault injection channel dynamically calls the error mode library according to the protocol type, achieving accurate verification of the communication fault tolerance mechanism. Multi-dimensional collection of response messages and verification of security rules ensure a comprehensive evaluation of the BMS hardware interface behavior, control logic, and security policies. This application's embodiments automate the construction and execution of complex test scenarios, reducing the error rate of manual configuration and improving testing efficiency; simultaneously, through timing and parameter threshold verification, the objectivity and reliability of test results are ensured, providing complete data support for BMS functional safety certification.

[0056] Please see Figure 2 This is a schematic diagram of a hardware-in-the-loop testing device for a battery management system provided in an embodiment of this application, including: The parameter acquisition unit 21 is used to acquire the hardware interface parameters and electrical characteristic parameters of the battery management system under test, wherein the electrical characteristic parameters include the target voltage platform; Resource determination unit 22 is used to determine the general hardware resources and redundancy interface strategy of the hardware-in-the-loop test bench based on the preset reference voltage platform and the target voltage platform. The rule generation unit 23 is used to generate interface mapping rules for the adapter harness of the hardware-in-the-loop test bench based on the redundancy interface strategy and hardware interface parameters. Hardware connection unit 24 is used to connect the signal conditioning module of the hardware-in-the-loop test bench and the battery management system under test through a transfer harness based on interface mapping rules. The instruction generation unit 25 is used to generate a set of simulation execution instructions for the real-time simulator of the hardware-in-the-loop test bench based on electrical characteristic parameters. The simulation test unit 26 is used to control the real-time simulator to perform signal simulation and fault injection tests based on the simulation execution instruction set, and output the simulation test results.

[0057] Please see Figure 3 This application also provides an electronic device 300, including a memory 310, a processor 320, and a computer program 311 stored in the memory 310 and executable on the processor. When the processor 320 executes the computer program 311, it implements the steps of a hardware-in-the-loop testing method for a battery management system.

[0058] Since the electronic device described in this embodiment is the device used to implement the hardware-in-the-loop testing device for a battery management system in this application embodiment, those skilled in the art can understand the specific implementation method and various variations of the electronic device in this embodiment based on the method described in this application embodiment. Therefore, how the electronic device implements the method in this application embodiment will not be described in detail here. Any device used by those skilled in the art to implement the method in this application embodiment is within the scope of protection of this application.

[0059] In practice, when the computer program 311 is executed by the processor, it can implement any of the embodiments corresponding to the first aspect.

[0060] It should be noted that the descriptions of each embodiment in the above embodiments have different focuses. For parts that are not described in detail in a certain embodiment, please refer to the relevant descriptions in other embodiments.

[0061] Those skilled in the art will understand that embodiments of this application can provide 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-readable storage media containing computer-readable program code.

[0062] 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 computer, 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, create a machine for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0063] 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.

[0064] 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.

[0065] This application also provides a computer program product, which includes computer software instructions that, when executed on a processing device, cause the processing device to perform... Figure 1 The flowchart of a hardware-in-the-loop testing method for a battery management system in a corresponding embodiment.

[0066] A computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the flow or function according to the embodiments of this application is generated. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions may be stored in a computer-readable storage medium or transferred from one computer-readable storage medium to another. For example, computer instructions may be transferred from one website, computer, server, or data center to another website, computer, server, or data center via wired or wireless means. The computer-readable storage medium may be any usable medium that a computer can store or a data storage device such as a server or data center that integrates one or more usable media. The usable medium may be a magnetic medium, an optical medium, or a semiconductor medium, etc.

[0067] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0068] In the several embodiments provided in this application, it should be understood that the disclosed devices, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; multiple units or components may be combined or integrated into another system, or some features may be omitted or not performed. Furthermore, the mutual couplings or direct couplings or communication connections shown or discussed may be indirect couplings or communication connections through some interfaces, devices, or units, and may be electrical, mechanical, or other forms.

[0069] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0070] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated units described above can be implemented in the form of hardware and / or software functional units.

[0071] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device to execute all or part of the steps of the methods in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory, magnetic disks, or optical disks.

[0072] The above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application.

[0073] Although preferred embodiments have been described in this specification, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications that fall outside the scope of this specification.

[0074] Obviously, those skilled in the art can make various modifications to this specification without departing from its spirit and scope. Therefore, this specification also intends to include any modifications that fall within the scope of the claims and their equivalents.

Claims

1. A hardware-in-the-loop testing method for a battery management system, characterized in that, include: Obtain the hardware interface parameters and electrical characteristic parameters of the battery management system under test, wherein the electrical characteristic parameters include the target voltage platform; Based on the preset reference voltage platform and the target voltage platform, the general hardware resources and redundancy interface strategy of the hardware-in-the-loop test bench are determined. Based on the redundant interface strategy and the hardware interface parameters, the interface mapping rules for the adapter harness of the hardware-in-the-loop test bench are generated. Based on the interface mapping rules, the signal conditioning module of the hardware-in-the-loop test bench and the battery management system under test are connected through the adapter harness. Based on the electrical characteristic parameters, a set of simulation execution instructions is generated in the real-time simulator of the hardware-in-the-loop test bench; Based on the simulation execution instruction set, the real-time simulator is controlled to perform signal simulation and fault injection tests, and the simulation test results are output.

2. The method according to claim 1, characterized in that, The determination of general hardware resources and redundancy interface strategies for the hardware-in-the-loop test bench based on the preset reference voltage platform and the target voltage platform includes: Based on the preset reference voltage platform, the general hardware channel type and number of channels of the hardware-in-the-loop test bench are determined; An electrical compatibility analysis is performed on the target voltage platform and the preset reference voltage platform to determine the unified electrical specifications of the functionally equivalent signal interface. The functionally equivalent signal interface is an interface that performs the same signal function in both the preset reference voltage platform and the target voltage platform. Based on the voltage range characteristics of the target voltage platform, determine the redundancy resource configuration strategy for the target voltage interface corresponding to the target voltage platform; Based on the aforementioned redundant resource configuration strategy, a physically isolated architecture is constructed; Based on the general hardware channel type, the number of channels, the unified electrical specifications, and the physical isolation architecture, the general hardware resources and redundancy interface strategy of the hardware-in-the-loop test bench are determined.

3. The method according to claim 1, characterized in that, The interface mapping rules for generating the adapter harness of the hardware-in-the-loop test bench based on the redundant interface strategy and the hardware interface parameters include: Based on the aforementioned redundant interface strategy, the reference voltage resource interface group and the target voltage resource interface group at the output of the signal conditioning module are determined. Based on the hardware interface parameters, the physical interface pin information of the battery management system under test is analyzed. Based on the electrical compatibility of the physical interface pin information with the reference voltage resource interface group and the target voltage resource interface group, the signal mapping relationship is determined. Based on the signal mapping relationship, an interface mapping rule for the adapter harness is generated, wherein the interface mapping rule is the pin connection logic between the output of the signal conditioning module and the physical interface of the battery management system under test.

4. The method according to claim 3, characterized in that, The signal conditioning module of the hardware-in-the-loop test bench and the battery management system under test are connected via the adapter harness based on the interface mapping rules, including: Based on the interface mapping rules, the pin connection logic of the adapter harness is determined; Based on the pin connection logic, the output interface of the signal conditioning module is physically connected to the physical interface of the battery management system under test.

5. The method according to claim 1, characterized in that, The electrical characteristic parameters include the target voltage platform, cell quantity parameters, and communication protocol type. The step of generating the simulation execution instruction set for the real-time simulator of the hardware-in-the-loop test bench based on the electrical characteristic parameters includes: Based on the cell quantity parameters, determine the number of individual voltage channels in the cell simulator; Based on the target voltage platform, determine the total voltage output range of the constant voltage source; Based on the communication protocol type, determine the protocol error mode library for the bus fault injection channel; The simulation execution instruction set is generated based on the number of individual voltage channels, the total voltage output range, and the protocol error mode library.

6. The method according to claim 5, characterized in that, The method of controlling the real-time simulator to perform signal simulation and fault injection tests based on the simulation execution instruction set, and outputting simulation test results, includes: Based on the number of voltage channels in a single cell, the cell simulator is controlled to output a programmable voltage sequence that matches the cell quantity parameter; Based on the total voltage output range, the constant voltage source is controlled to output a DC voltage signal corresponding to the target voltage platform; Based on the protocol error mode library, the bus fault injection channel is controlled to perform preset communication protocol error injection operations; Collect the response messages of the battery management system under test to the programmable voltage sequence, the DC voltage signal, and the protocol error injection operation; Based on preset security judgment rules, the response message is verified to generate the simulation test results.

7. A hardware-in-the-loop testing device for a battery management system, characterized in that, include: The parameter acquisition unit is used to acquire the hardware interface parameters and electrical characteristic parameters of the battery management system under test, wherein the electrical characteristic parameters include the target voltage platform; The resource determination unit is used to determine the general hardware resources and redundancy interface strategy of the hardware-in-the-loop test bench based on the preset reference voltage platform and the target voltage platform. The rule generation unit is used to generate interface mapping rules for the adapter harness of the hardware-in-the-loop test bench based on the redundant interface strategy and the hardware interface parameters. A hardware connection unit is used to connect the signal conditioning module of the hardware-in-the-loop test bench and the battery management system under test through the adapter harness, based on the interface mapping rules. The instruction generation unit is used to generate a set of simulation execution instructions in the real-time simulator of the hardware-in-the-loop test bench based on the electrical characteristic parameters. The simulation test unit is used to control the real-time simulator to perform signal simulation and fault injection tests based on the simulation execution instruction set, and output the simulation test results.

8. An electronic device, comprising: A memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that the processor, when executing the computer program stored in the memory, implements the steps of the hardware-in-the-loop testing method for the battery management system as described in any one of claims 1 to 6.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the steps of the hardware-in-the-loop testing method for the battery management system as described in any one of claims 1 to 6.

10. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by the processor, it implements the steps of the hardware-in-the-loop testing method for the battery management system as described in any one of claims 1 to 6.

Images