Test systems and methods for battery management systems

Abstract

This application discloses a testing system and method for a battery management system, relating to the field of battery testing technology. The testing system includes multiple independent test channels, each with corresponding channel test resources; a shared resource pool, including shared test resources for use by multiple test channels; a virtual machine for compiling test scripts into intermediate bytecode, which is then parsed by a control center to obtain test tasks; a control center, including a resource scheduling engine for constructing a directed acyclic graph of test tasks and allocating shared test resources; and a master controller and slave controllers corresponding to each test channel. The master controller sends broadcast signals to the slave controllers, enabling each test channel to execute test operations corresponding to the test tasks in parallel based on the allocated shared test resources and channel test resources. This solves the technical problem of improving the testing efficiency of battery management systems.

Description

Technical Field

[0001] This application relates to the field of battery testing technology, and more specifically, to a testing system and method for a battery management system. Background Technology

[0002] In the field of new energy vehicles, to improve driving range, safety, and comfort, a Battery Management System (BMS) is needed to accurately monitor battery status and efficiently control the charging and discharging process. In the energy storage systems of new energy vehicles, to ensure the reliable operation of the BMS under various complex conditions, comprehensive and accurate testing and verification must be performed during the R&D and production stages. Traditional BMS testing systems typically employ a single-channel serial execution architecture, resulting in low testing efficiency. Therefore, a key technical challenge exists: how to improve the testing efficiency of battery management systems.

[0003] Regarding the technical problem of how to improve the testing efficiency of battery management systems in related technologies, no effective solution has yet been proposed. Summary of the Invention

[0004] This application provides a testing system and method for a battery management system, which at least addresses the technical problem of how to improve the testing efficiency of a battery management system in related technologies.

[0005] According to one embodiment of this application, a test system for a battery management system is provided, comprising: multiple independent test channels, each test channel corresponding to channel test resources, wherein the test resources represent the test capabilities provided by the hardware device for testing the battery management system; a shared resource pool, including shared test resources for use by the multiple test channels; a virtual machine, used to compile test scripts into intermediate bytecode, so that a control center can parse the intermediate bytecode to obtain test tasks, wherein the test tasks are used for test operations on different battery management systems; the control center includes a resource scheduling engine, which is used to construct a directed acyclic graph of the test tasks and allocate the shared test resources according to the directed acyclic graph and the resource occupancy status of the shared resource pool; the control center further includes a master controller and a slave controller corresponding to each test channel, wherein the master controller is used to generate a standard time for the hardware clock and send a broadcast signal to the slave controller based on the standard time, so that each test channel can execute the test operations corresponding to the test tasks in parallel based on the allocated shared test resources and the channel test resources.

[0006] According to another embodiment of this application, a testing method for a battery management system is provided, comprising: parsing a test script to obtain a test task, wherein the test task is used for test operations on different battery management systems; constructing a directed acyclic graph of the test task; allocating shared test resources of the shared resource pool to multiple test channels according to the directed acyclic graph and the resource occupancy status of the shared resource pool; and executing the test operations corresponding to the test task in parallel based on the allocated shared test resources and the channel test resources of the multiple test channels.

[0007] According to another aspect of the embodiments of this application, a computer-readable storage medium is also provided, wherein a computer program is stored in the computer program, and the computer program is configured to execute the test method of the battery management system described above when running.

[0008] According to another aspect of the embodiments of this application, an electronic device is also provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the test method of the battery management system through the computer program.

[0009] According to another aspect of the embodiments of this application, a computer program product is also provided, including a computer program that, when executed by a processor, implements the steps of the methods described in various embodiments of this application.

[0010] This application proposes a battery management system testing system, comprising: multiple independent test channels, each test channel corresponding to channel test resources, wherein the test resources represent the testing capabilities provided by the hardware device for testing the battery management system; a shared resource pool, including shared test resources for use by the multiple test channels; a virtual machine, used to compile test scripts into intermediate bytecode, so that a control center can parse the intermediate bytecode to obtain test tasks, wherein the test tasks are used for test operations on different battery management systems; the control center includes a resource scheduling engine, which is used to construct a directed acyclic graph of the test tasks and allocate the shared test resources according to the directed acyclic graph and the resource occupancy status of the shared resource pool; the control center also includes a master controller and a slave controller corresponding to each test channel, wherein the master controller is used to generate a standard time for the hardware clock and send a broadcast signal to the slave controller based on the standard time, so that each test channel can execute the test operations corresponding to the test tasks in parallel based on the allocated shared test resources and the channel test resources. Through the aforementioned multi-channel parallel testing architecture, multiple BMS or BMS components can simultaneously execute test tasks on their respective independent channels. Shared resources are dynamically allocated by the resource scheduling engine based on a directed acyclic graph, avoiding resource idleness and task blocking in traditional serial testing. Simultaneously, the main controller achieves nanosecond-level synchronous triggering of all channels through hardware clock broadcasting, significantly improving test parallelism and execution efficiency. This solves the technical problem of how to improve the testing efficiency of battery management systems, thereby enhancing the testing efficiency of battery management systems. Attached Figure Description

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

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

[0013] Figure 1 This is a schematic diagram of the structure of a test system for a battery management system according to an embodiment of this application;

[0014] Figure 2 This is a schematic diagram of the structure of a resource scheduling engine according to an embodiment of this application;

[0015] Figure 3This is a schematic diagram of channel test resources according to an embodiment of this application;

[0016] Figure 4 This is a schematic diagram illustrating the connection relationship between shared test resources and test channels according to an embodiment of this application;

[0017] Figure 5 This is a schematic flowchart of a test method for a battery management system according to an embodiment of this application. Detailed Implementation

[0018] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort should fall within the scope of protection of the present application.

[0019] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0020] However, there may be instances where unnecessary detailed descriptions are omitted. For example, detailed descriptions of well-known matters or repetitive descriptions of essentially the same structure may be omitted. This is to avoid making the following description unnecessarily lengthy and to facilitate understanding by those skilled in the art. Furthermore, the following description is provided to enable those skilled in the art to fully understand this application and is not intended to limit the subject matter of the claims.

[0021] A battery management system (BMS) is an electronic system used to monitor and manage battery packs, especially large packs composed of multiple cells, such as those in electric vehicles and energy storage systems. Its main functions include:

[0022] Battery status monitoring: Real-time monitoring of key parameters such as battery voltage, current, temperature, and state of charge to ensure that the battery operates within a safe range.

[0023] Balanced management: By controlling the charging and discharging process of each cell in the battery pack, the energy distribution among the cells is balanced, preventing overcharging and discharging of any part, thereby extending the overall lifespan of the battery pack.

[0024] Fault diagnosis and early warning: When abnormal conditions are detected, such as overheating, overcharging, over-discharging, short circuit, etc., the battery management system can react quickly, issue alarm signals and take necessary protective measures, such as suspending charging and cutting off the circuit, to prevent battery damage or safety accidents.

[0025] Safety Management: During battery pack operation, the battery management system implements various safety strategies, such as overcurrent protection, thermal runaway prevention, and battery status assessment, to ensure the safe operation of the battery pack.

[0026] Communication and Control: The battery management system typically communicates with the vehicle controller, the central control unit of the energy storage system, or other external devices to provide battery status information and receive control commands from the outside, such as adjusting the charging rate and reporting battery health status.

[0027] Data recording and analysis: Record the battery pack's operating data for later analysis of battery performance, prediction of lifespan, and assessment of the overall system health.

[0028] Battery management systems are an indispensable component in applications such as electric vehicles, energy storage systems, and portable electronic devices. They play the role of a guardian of battery health, ensuring that the battery operates in optimal condition through sophisticated algorithms and sensor networks, while minimizing the occurrence of safety accidents.

[0029] Figure 1 This is a structural block diagram of a test system for a battery management system according to an embodiment of this application; as shown below. Figure 1 As shown, the test system for the battery management system includes:

[0030] Multiple independent test channels, corresponding to Figure 1 The test channels 1 to N are provided, and each test channel has corresponding channel test resources. The test resources represent the test capabilities provided by the hardware devices used to test the battery management system.

[0031] The shared resource pool 14 includes shared test resources for use by the multiple test channels;

[0032] Virtual machine 10 is used to compile test scripts into intermediate bytecode, so that control center 12 can parse the intermediate bytecode to obtain test tasks;

[0033] The control center 12 includes a resource scheduling engine 122, which is used to construct a directed acyclic graph of the test task and allocate the shared test resources according to the directed acyclic graph and the resource occupancy status of the shared resource pool 14.

[0034] The control center 12 also includes a master controller 120 and slave controllers corresponding to each test channel, corresponding to slave controllers 1 to N in the figure. The master controller 120 is used to generate a standard time for the hardware clock and send a broadcast signal to the slave controllers based on the standard time, so that each test channel can execute the test operation corresponding to the test task in parallel based on the allocated shared test resources and the channel test resources.

[0035] The battery management system test system provided in this embodiment includes multiple independent test channels, a shared resource pool, a virtual machine, and a control center. Each test channel has independent channel test resources, which refer to the test capabilities provided by the hardware devices used to test the battery management system (BMS), such as an adjustable power supply to simulate battery voltage and a daisy-chain simulator to simulate communication topology. The shared resource pool contains shared test resources for multiple test channels, such as a high-voltage insulation tester and an insulation impedance simulation array. The virtual machine compiles user-written test scripts into intermediate bytecode, which is then parsed by the control center to obtain test tasks. The control center has a resource scheduling engine that constructs a directed acyclic graph (DAG) of test tasks and dynamically allocates shared test resources based on the DAG and the resource occupancy status of the shared resource pool. The control center also includes a master controller and slave controllers corresponding to each test channel. The master controller generates a standard time for the hardware clock and sends broadcast signals to each slave controller based on this standard time, enabling each test channel to perform test operations in parallel based on the allocated shared test resources and its own channel test resources. For example, when testing two BMSs simultaneously, channel 1 performs overcharge protection testing, while channel 2 performs over-discharge protection testing. The two systems operate independently, achieving nanosecond-level synchronous startup via broadcast signals. This architecture enables multi-channel parallel testing, significantly improving testing efficiency while maintaining testing accuracy and resource utilization.

[0036] In one exemplary embodiment, the master controller is connected to the slave controllers via a low-voltage differential signal bus to form a bus structure. The low-voltage differential signal transmitting end of the master controller is connected to the low-voltage differential signal receiving end of the slave controller. The master controller sends the broadcast signal to the slave controllers via the low-voltage differential signal bus.

[0037] Optionally, in the above embodiments, the master controller is connected to each slave controller via a Low-Voltage Differential Signaling (LVDS) bus, forming a bus structure. Specifically, the LVDS transmitter of the master controller is connected to the LVDS receiver of each slave controller via differential cables, and the master controller uses this LVDS bus to send broadcast signals to all slave controllers. This connection method ensures high-speed signal transmission and anti-interference capability, while enabling the broadcast signal to reach all slave controllers simultaneously, providing a physical basis for hardware-level synchronous triggering. Compared with traditional serial communication or software triggering, the LVDS bus structure can control the inter-channel trigger jitter within a very short time, significantly improving the synchronization accuracy of multi-channel testing.

[0038] In one exemplary embodiment, the master controller further includes a crystal oscillator and a clock distribution circuit, the output of the crystal oscillator being connected to the input of the clock distribution circuit. The master controller is further configured to generate the standard time and send a broadcast signal to the slave controller based on the standard time by: converting the original clock signal generated by the crystal oscillator into the standard time and distributing the standard time to the slave controller via the low-voltage differential signal bus; generating a synchronization trigger instruction based on the standard time and sending the synchronization trigger instruction to the slave controller via the broadcast signal, wherein the synchronization trigger instruction is used to instruct the plurality of test channels to start testing simultaneously.

[0039] Optionally, in the above embodiments, the main controller further includes a crystal oscillator and a clock distribution circuit. The output of the crystal oscillator is connected to the input of the clock distribution circuit. The main controller generates a standard time and sends a broadcast signal based on this standard time in the following manner: First, the original clock signal generated by the crystal oscillator is converted into a high-precision hardware clock reference, i.e., the standard time, and distributed to each slave controller via the LVDS bus, so that all slave controllers obtain a unified clock source with a clock deviation of no more than 10 nanoseconds; then, a synchronization trigger command is generated based on the standard time and sent to each slave controller via a broadcast signal. This synchronization trigger command is used to instruct multiple test channels to start testing simultaneously. For example, when all channels need to apply a voltage ramp simultaneously, the main controller issues a broadcast synchronization trigger command at a certain clock edge of the standard time, and each slave controller responds at the same clock edge, realizing hardware-level synchronization of actions between channels and eliminating the uncertainty of software synchronization.

[0040] In an exemplary embodiment, the master controller is further configured to send a broadcast signal to the slave controller in the following manner: acquiring a low-voltage differential signal broadcast frame, wherein the frame structure of the broadcast frame includes a frame header field, an instruction code field, a parameter field, and a check field, the frame header field includes a unique broadcast identifier, the instruction code field includes a synchronization trigger instruction, a parameter configuration instruction, and a start / stop control instruction, and the parameter field includes test parameters corresponding to the parameter configuration instruction; sending the broadcast frame to the slave controller, so that after receiving the broadcast frame, the slave controller verifies the broadcast frame based on the check field, and after the verification is successful, controls the hardware device in each test channel to perform the test operation according to the instruction code field and the parameter field.

[0041] Optionally, in the above embodiments, the master controller sends broadcast signals to each slave controller in the following way: It acquires a predefined LVDS broadcast frame, the frame structure of which sequentially includes a frame header field, an instruction code field, a parameter field, and a check field. The frame header field contains a unique broadcast identifier to identify that the frame belongs to the broadcast type; the instruction code field includes synchronization trigger instructions, parameter configuration instructions, or start / stop control instructions, etc.; the parameter field includes test parameters corresponding to the parameter configuration instructions, such as an overvoltage threshold of 3.7V and a sampling period of 0.1 seconds; the check field is used for subsequent integrity verification. The master controller sends the broadcast frame to all slave controllers via the LVDS bus. After receiving the frame, the slave controller performs verification based on the check field. If the verification passes, it executes the corresponding test operation according to the instruction code and parameter field. For example, the master controller broadcasts a "parameter configuration" instruction, setting the current threshold of all channels to 100A. Each channel simultaneously updates its local parameters, eliminating the need for manual setting. This frame structure design ensures the reliability and scalability of broadcast communication.

[0042] In an exemplary embodiment, the slave controller is further configured to verify the broadcast frame by: upon receiving the broadcast frame, performing a cyclic redundancy check on the verification field of the broadcast frame to determine the integrity of the broadcast frame; if the verification passes, executing instructions obtained by parsing the broadcast frame; if the verification fails, sending a retransmission request signal to the master controller to cause the master controller to retransmit the broadcast frame.

[0043] Optionally, in the above embodiments, after receiving a broadcast frame, the slave controller first performs a cyclic redundancy check (CRC) on the check field of the frame to determine whether an error occurred during transmission. If the check passes, the frame is intact, and the instruction code and parameter fields in the frame are parsed, and the corresponding instruction is executed immediately. If the check fails, the broadcast frame may be interfered with or damaged, and the slave controller sends a retransmission request signal to the master controller via the LVDS bus. Upon receiving this signal, the master controller retransmits the original broadcast frame. For example, in a test environment with strong electromagnetic interference, a broadcast frame may have individual bits flipped due to noise. After detecting the error via CRC, the slave controller requests a retransmission, and the master controller retransmits the frame, ensuring the correct issuance of the instruction. This mechanism significantly enhances the system's anti-interference capability and communication reliability in industrial environments.

[0044] In an exemplary embodiment, the resource scheduling engine is used to construct a directed acyclic graph (DAG) of the test task by: decomposing the test task into multiple indivisible atomic tasks, creating a task node corresponding to each atomic task, wherein the attributes of the task node include task identifier, execution time, required resource list, and priority; determining the initial directed edges of the DAG based on the constraints between the multiple atomic tasks, wherein the initial directed edges are used to indicate the execution order between the task nodes, and the execution order satisfies the constraints; performing cycle dependency detection on the initial graph structure formed by the task nodes and the initial directed edges, and obtaining a detection result; if the detection result indicates that there is no cycle dependency between the task nodes, obtaining the DAG based on the initial graph structure; if the detection result indicates that there is a cycle dependency between the task nodes, adjusting the initial directed edges of the initial graph structure based on the constraints, obtaining an adjusted graph structure formed by the task nodes and the adjusted directed edges, and determining the DAG based on the adjusted graph structure, wherein there is no cycle dependency between the task nodes in the adjusted graph structure.

[0045] Optionally, in the above embodiments, the test task is first decomposed into multiple indivisible atomic tasks according to functional boundaries. Each atomic task corresponds to a task node, and the node attributes include task identifier (e.g., "voltage output"), execution time (e.g., 20ms), required resource list (e.g., "high voltage insulation tester"), and priority (higher values ​​indicate higher priority). Then, initial directed edges are determined based on the constraints between the multiple atomic tasks. The initial directed edges indicate the execution order between task nodes, and this order must satisfy the constraints (e.g., power-on must precede communication). Next, a cycle dependency detection is performed on the initial graph structure formed by the task nodes and the initial directed edges to obtain the detection results. If there are no cycle dependencies, the initial graph structure is directly used as a DAG; if there are cycle dependencies (e.g., A depends on B, B depends on C, C depends on A), the initial directed edges are adjusted based on the constraints (adjusting the dependency direction) until there are no cycle dependencies in the graph, ultimately obtaining a schedulable DAG. For example, the overcharge protection test is decomposed into "power-on → communication handshake → voltage output → protection delay monitoring," and these dependencies form an acyclic chain, directly constituting a DAG. The above embodiments ensured the correctness and deadlock-free nature of the test task dependencies, laying the foundation for subsequent scheduling.

[0046] In an exemplary embodiment, determining the initial directed edges of the directed acyclic graph based on the constraint relationships between the plurality of atomic tasks includes: determining the initial directed edges of the directed acyclic graph based on the logical dependencies between the plurality of atomic tasks and the mutual exclusion relationships arising from the plurality of atomic tasks requesting the same shared test resource, wherein the constraint relationships include the logical dependencies and the mutual exclusion relationships.

[0047] Optionally, in the above embodiments, when determining the initial directed edges of the directed acyclic graph (DAG), the resource scheduling engine specifically determines them based on the logical dependencies between multiple atomic tasks and the mutual exclusion relationships arising from requesting the same shared test resource. Logical dependencies stem from the natural order of test steps; for example, "communication handshake" must be completed before "voltage output," as determined by the BMS test specification. Mutual exclusion stems from the exclusivity of shared resources; for example, atomic tasks in channel A and channel B both require the use of a high-voltage insulation tester, which can only serve one task at a time. Therefore, an implicit mutual exclusion order arises between the two atomic tasks: whoever obtains the resource first executes first, and the other must wait. By incorporating these two constraints into the DAG construction, it is ensured that the DAG reflects both the test logic and resource contention, thereby avoiding resource conflicts during scheduling.

[0048] In an exemplary embodiment, the resource scheduling engine is configured to allocate the shared test resources based on the directed acyclic graph and the resource occupancy status of the shared resource pool in the following manner: performing topological sorting on the task nodes of the directed acyclic graph to obtain a task node execution sequence; determining a set of tasks that can be executed in parallel based on the task node execution sequence; performing resource conflict detection on atomic tasks in the set of tasks that can be executed in parallel, and determining a resource conflict if the resource lists required by two or more atomic tasks include the same shared test resource; and allocating shared test resources to the atomic tasks with resource conflicts based on the priority of the atomic tasks with resource conflicts and the real-time occupancy status of each shared test resource in the shared resource pool.

[0049] Optionally, in the above embodiments, firstly, the task nodes of the DAG are topologically sorted to obtain a task node execution sequence. Nodes at the same level in this sequence represent a set of tasks that are independent and can be executed in parallel. Then, the set of tasks that can be executed in parallel is determined based on this sequence. Next, resource conflict detection is performed on the atomic tasks in the set of tasks that can be executed in parallel: if the resource lists required by two or more atomic tasks contain the same shared test resource (e.g., both require the use of a high-voltage insulation tester), it is determined to be a resource conflict. Finally, resource allocation is performed on the conflicting tasks based on their priorities and the real-time occupancy status (idle or occupied) of each shared test resource in the shared resource pool. For example, after topological sorting, the task node execution sequence {T1, T2, T3 / T4, T5} is obtained, and the set of tasks that can be executed in parallel is {T3, T4}. T3 has a priority of 5 and requires a high-voltage insulation tester, while T4 has a priority of 3 and also requires the same tester. Since the tester is currently idle, it is prioritized for T3 to execute, and T4 enters the waiting queue. This allocation method effectively solves the resource contention problem in parallel testing and improves resource utilization and test throughput.

[0050] In an exemplary embodiment, the resource scheduling engine is configured to allocate shared test resources to the atomic tasks with resource conflicts in the following manner: allocate the shared test resources to the atomic task with the highest priority among the atomic tasks with resource conflicts; and add the atomic tasks other than the atomic task with the highest priority among the atomic tasks with resource conflicts to the waiting queue in descending order of priority.

[0051] Optionally, in the above embodiments, firstly, the requested shared test resources are allocated to the atomic task with the highest priority among the conflicting tasks, allowing it to execute immediately; then, the other atomic tasks in the conflicting tasks, excluding the highest priority task, are added to the waiting queue in descending order of priority. Tasks in the waiting queue receive their execution opportunities sequentially after the resources are released. For example, if there are three conflicting tasks A (priority 9), B (priority 5), and C (priority 7), resources are allocated first to A for execution, and then C and B are added to the waiting queue in priority order (C before B). This priority-based allocation strategy ensures that critical test tasks (such as fault injection tests) can be executed first, avoiding delays in important test projects due to resource waiting.

[0052] In an exemplary embodiment, the resource scheduling engine further includes a time window scheduling module, which is used to: divide the total test duration into multiple consecutive time windows according to the execution time of atomic tasks in the directed acyclic graph; and allocate the multiple atomic tasks to the corresponding time windows, wherein atomic tasks in the set of tasks that can be executed in parallel are allocated to the same time window for parallel execution.

[0053] Optionally, in the above embodiments, such as Figure 2As shown, the resource scheduling engine 122 also includes a time window scheduling module 1221. For example, taking "voltage sampling accuracy test" as an example, the time window scheduling module first decomposes the test into an atomic task sequence: A1 (single voltage acquisition, time 10ms), A5 (data calibration, time 5ms), A6 (data comparison with threshold, time 10ms), and A4 (data upload, time 5ms). The four atomic tasks are executed sequentially, with a total time of 30ms. Based on the FPGA hardware clock, the time window scheduling module divides a variable long time window W1 with a window length of 50ms. This window length is not less than the total time of the atomic tasks (30ms), while reserving 20ms of redundancy to match the subsequent idle detection threshold. Then, the atomic task sequence [A1-1, A5-1, A6-1, A4-1] of channel 1 and the atomic task sequence [A1-2, A5-2, A6-2, A4-2] of channel 2 are all included in W1. Since the atomic tasks of the two channels each rely on their own independent voltage sampling modules, there are no resource conflicts between them. Therefore, they can be executed completely in parallel within W1: Channel 1 executes A1-1→A5-1→A6-1→A4-1 sequentially, while Channel 2 executes A1-2→A5-2→A6-2→A4-2 sequentially. The atomic tasks with the same sequence number in the two channels are actually executed in time-aligned. After completing W1, the subsequent "current sampling test" atomic task sequence is assigned to W2 (window length 50ms), and the "fault injection test" is assigned to W3 (window length 50ms), realizing the ordered scheduling of atomic tasks of different test steps within different time windows. By dividing the time windows, the globally complex parallel scheduling problem is decomposed into local scheduling within multiple time windows, reducing the complexity of the scheduling algorithm, while ensuring the orderliness and predictability of multi-channel test tasks in the time dimension, significantly improving the system's scheduling efficiency and test throughput.

[0054] In an exemplary embodiment, the time window scheduling module is further configured to: establish a resource request table for atomic tasks allocated to the same time window, the resource request table being used to record the type of shared test resources requested by each atomic task and the scheduled execution time; traverse the atomic tasks in the resource request table in descending order of priority, allocate the requested shared test resources to the first atomic task, and mark the allocated shared test resources as occupied, wherein the first atomic task is the currently traversed atomic task; and if the shared test resources requested by the second atomic task in the resource request table are already occupied, adjust the execution time of the second atomic task in the current time window, or allocate the second atomic task to the next time window.

[0055] Optionally, in the above embodiments, firstly, a resource request table is established for atomic tasks allocated to the same time window. This table records the type of shared test resource requested by each atomic task and its scheduled execution time within the time window. Then, the atomic tasks in the resource request table are traversed in descending order of priority. The requested shared test resource is allocated to the first atomic task currently being traversed, and the resource is marked as occupied. For the second atomic task in the resource request table, if the requested resource is already occupied, the execution time of the second atomic task within the current time window is adjusted (e.g., delayed by a few milliseconds for time-sharing multiplexing), or the second atomic task is moved out of the current time window and allocated to the next time window. The above process is repeated until all tasks within the time window are scheduled. For example, in window W2, if high-priority task T3 occupies the high-voltage tester for 0-10ms, and low-priority task T4 also requests the same tester, the execution time of T4 is adjusted to 10-20ms to achieve time-sharing multiplexing; if the execution time of T4 exceeds the remaining time within the window, it is moved to window W3. This method minimizes resource conflicts within a time window, ensuring the schedulability of tasks within the window.

[0056] In an exemplary embodiment, the resource scheduling engine further includes a monitoring module, which is configured to: monitor a target test channel; determine idle test resources from the target test channel, wherein the idle test resources represent test resources with a continuous idle duration greater than a preset duration; obtain target atomic tasks to be executed from the waiting queues of other test channels, wherein the other test channels are channels other than the target test channel among the plurality of test channels, and the task type of the target atomic task to be executed is a task type supported by the idle test resources; and migrate the target atomic task to be executed to the target test channel to execute the atomic task through the idle test resources.

[0057] Optionally, in the above embodiments, such as Figure 2As shown, the resource scheduling engine 122 also includes a monitoring module 1222. This monitoring module monitors the target test channel and identifies idle test resources within it. Idle test resources are those with a continuous idle duration exceeding a preset duration (e.g., 50ms). For example, if the main controller detects that the equalization simulation module in channel 1 is idle for 60ms consecutively between 100-160ms, exceeding the 50ms threshold, it determines that the resource is idle. Then, the monitoring module retrieves target atomic tasks to be executed from the waiting queues of other test channels (such as channel 2). The task type of this task must be a type supported by the idle test resources. Finally, the target atomic task to be executed is migrated to the target test channel and executed in advance using the idle test resources. For example, the low-priority "data reporting" task in channel 2 is migrated to the idle period (100-110ms) of channel 1 for execution. Through task migration, the system can fill idle segments, improve overall resource utilization, and thus shorten the overall test time.

[0058] In one exemplary embodiment, the channel test resources for each test channel include at least the test capabilities provided by an adjustable power supply, a bidirectional load, a data acquisition unit, a daisy-chain simulator, and a fault injection matrix, and each test channel is isolated from other test channels.

[0059] Optionally, in the above embodiments, such as Figure 3 As shown, the channel test resources for each test channel include at least the test capabilities provided by an adjustable power supply, a bidirectional load, a data acquisition unit, a daisy-chain simulator, and a fault injection matrix. The adjustable power supply simulates the battery's voltage output, the bidirectional load simulates the charging and discharging current, the data acquisition unit samples data reported by the BMS in real time, the daisy-chain simulator simulates the daisy-chain communication topology between battery modules, and the fault injection matrix injects fault signals such as voltage anomalies, temperature anomalies, and communication interruptions into the BMS. Each test channel is physically isolated from other test channels; that is, the aforementioned hardware devices for each channel are independently configured, with no electrical connection between them, and a shielding structure is provided between adjacent channels. For example, a short-circuit fault in the fault injection matrix of channel 1 will not affect the normal testing of channel 2. This isolation design ensures the reliability of parallel testing and avoids the propagation of single-point faults.

[0060] In one exemplary embodiment, the shared test resources include at least the test capabilities provided by a high-voltage insulation tester and an insulation impedance simulation array; the high-voltage insulation tester is connected to the plurality of test channels respectively through a first switching array, and the insulation impedance simulation array is connected to the plurality of test channels respectively through a second switching array; the control terminals of the first switching array and the second switching array are both connected to the control center; the control center is also used to allocate the shared test resources by controlling the first switching array and the second switching array.

[0061] Optionally, in the above embodiments, such as Figure 4 As shown, the shared test resources of the shared resource pool 14 include at least the testing capabilities provided by the high-voltage insulation tester 141 and the insulation impedance simulation array 142. The high-voltage insulation tester is used to perform insulation withstand voltage tests on the BMS, and it is connected to multiple test channels through the first switching array 15. The insulation impedance simulation array is used to simulate the insulation impedance changes between the battery pack and the chassis, and it is connected to multiple test channels through the second switching array 16. The control terminals of both the first and second switching arrays are connected to the control center 12, which allocates the shared test resources by controlling these switching arrays. For example, when channel 1 needs to perform an insulation test, the control center closes the switch in the first switching array that connects channel 1 to the high-voltage insulation tester, while simultaneously opening the switches of other channels, allowing channel 1 to exclusively use the tester; after the test is completed, the switch is released for use by other channels. This design of a shared resource pool plus switching arrays satisfies the on-demand access of multiple channels to expensive test equipment, while avoiding the increased cost of configuring the same equipment for each channel.

[0062] In one optional embodiment, a BMS multi-channel parallel testing system and its testing method are provided, which will be described in detail below with reference to specific testing scenarios.

[0063] I. System Architecture:

[0064] The BMS multi-channel parallel testing system in this embodiment includes: 4 independent test channels (channel 1 to channel 4), a shared resource pool, a real-time controller, and a virtual machine.

[0065] Each independent test channel is equipped with a complete set of independent test resources, including: an adjustable power supply, a bidirectional load, a data acquisition unit, a daisy-chain simulator, and a fault injection matrix (relay array, supporting voltage / temperature / communication fault injection). The hardware resources of each channel are physically isolated from each other, and metal shielding plates are installed between adjacent channels, so that a hardware failure in one channel will not affect the normal testing of other channels.

[0066] The shared resource pool includes a high-voltage insulation tester (500V-5000V) and an insulation impedance simulation array (100kΩ-100MΩ adjustable). The high-voltage insulation tester is connected to four test channels via a first switching array (4-to-1 relay matrix), and the insulation impedance simulation array is connected to the four test channels via a second switching array. The control terminals of both switching arrays are connected to a real-time controller, which allocates shared resources as needed.

[0067] The real-time controller adopts an FPGA master-slave architecture: the master controller and each slave controller are connected via an LVDS bus. The LVDS transmitter of the master controller is connected to the LVDS receiver of each slave controller via differential shielded twisted-pair cables, forming a physical topology combining star and bus topologies. The master controller has an onboard temperature-compensated crystal oscillator, the output of which is connected to a clock distribution circuit. The clock distribution circuit converts the original clock signal into a unified hardware clock reference and distributes it to all slave controllers via the LVDS bus, ensuring that the clock deviation between the master and slave controllers is ≤10ns.

[0068] The virtual machine runs on an industrial control computer and uses test scripts written in DSL (Domain-Specific Language). These scripts contain parallel process blocks and synchronization barriers. The virtual machine compiler compiles the DSL scripts into intermediate bytecode, which is hardware-platform independent and is loaded and executed by the bytecode interpreter within the real-time controller.

[0069] II. Test Tasks and Synchronization Triggers:

[0070] This embodiment uses four test channels simultaneously to perform overcharge protection testing on four BMS units. After the user writes the test script, the virtual machine compiles it into intermediate bytecode, and the real-time controller parses it to obtain the test task. The master controller generates a unified hardware clock reference through the onboard temperature-compensated crystal oscillator and clock distribution circuit, and distributes it to each slave controller through the LVDS bus. The clock deviation between the master and slave controllers does not exceed 10 nanoseconds.

[0071] Before the test begins, the master controller first constructs a parameter configuration broadcast frame. The frame header contains a broadcast identifier, the instruction code is the parameter configuration command, and the parameter field includes a channel mask (indicating the channels to be configured; in this example, all four channels), the parameter type (overvoltage protection threshold), and the threshold value (100 millivolts). A cyclic redundancy check (CRC) code is appended to the frame tail. The master controller sends this broadcast frame to all slave controllers via the LVDS bus. Each slave controller receives the frame, performs hardware verification on the CRC code, and upon successful verification, parses the parameter field and synchronously updates its local overvoltage protection threshold to 100 millivolts.

[0072] Subsequently, the master controller constructs a synchronization trigger broadcast frame. This broadcast frame also has a broadcast identifier in its header, a synchronization trigger command in its instruction code, a start sequence number (used to identify the sequence number of this trigger) in its parameter field, and a checksum at the end of the frame. The master controller sends this broadcast frame to all slave controllers on a specific rising edge of the unified hardware clock. After each slave controller receives and verifies the frame, it simultaneously responds on the next rising edge of the unified hardware clock, beginning to execute the test tasks of its respective channel, achieving nanosecond-level synchronous startup.

[0073] By configuring the parameters and synchronously triggering the broadcast frames as described above, all channels start testing at the same time, ensuring the accuracy and comparability of timing measurement results such as overcharge protection delay.

[0074] III. Task Decomposition and DAG Construction:

[0075] Taking the overcharge protection test of channel 1 as an example, the resource scheduling engine decomposes the test task into the following atomic tasks according to the functional boundaries: A1: power-on (10ms), A2: communication handshake (5ms), A3: voltage output (20ms), A4: protection delay monitoring (10ms), A5: fault injection (5ms), A6: data reporting (5ms).

[0076] The directed edges are determined based on the test logic dependencies: A1→A2→A3→A4, A3→A5. Simultaneously, since both A4 and A5 request the high-voltage insulation tester from the shared resource pool (A4 needs to measure insulation impedance, A5 needs to verify fault isolation effectiveness), a mutually exclusive order relationship arises. Therefore, a virtual directed edge is added (e.g., A4 precedes A5, or this is determined by priority). After cycle dependency detection, the graph is acyclic, resulting in a Directed Acyclic Graph (DAG). Similar decomposition is performed for channels 2, 3, and 4, yielding their respective DAGs. The resource scheduling engine performs topological sorting on each DAG. Taking channel 1 as an example, the topological sorting results in the execution sequence: A1, A2, A3, A4 / A5 (parallel), A6. A4 and A5 have no dependency relationship and can be executed in parallel.

[0077] IV. Time Window Division and Resource Scheduling:

[0078] The resource scheduling engine further invokes the time window scheduling module. This module generates a time window baseline based on the FPGA hardware clock, dividing the total test duration into multiple consecutive time windows. The window length is dynamically configured based on the execution time of the atomic tasks.

[0079] For example, allocate A1 (10ms), A2 (5ms), and A3 (20ms) of channel 1 to window W1, with a window length set to 35ms (total time 35ms). Allocate A4 (10ms) and A5 (5ms) to window W2, with a window length set to 15ms. Allocate A6 (5ms) to window W3, with a window length of 5ms. Since A4 and A5 can run in parallel within window W2, the actual window length is set according to the longest one (10ms), and the window length is still 15ms (including redundancy).

[0080] For similar tasks in Channel 2, their atomic tasks are also assigned to the corresponding time windows. Within window W2, A4 and A5 in Channel 1 request the high-voltage insulation tester and the daisy-chain simulator, respectively, while the corresponding task in Channel 2 also requests the high-voltage insulation tester. The time window scheduling module establishes a resource request table, recording the resource type and execution time requested by each atomic task. Allocation is based on priority: A4 (priority 5) has priority to use the high-voltage insulation tester, and the execution time of similar tasks in Channel 2 (priority 4) is adjusted, time-sharing the tester (A4 0-10ms, Channel 2 task 10-20ms). Tasks without conflicts (such as A5 relying on the daisy-chain simulator) are executed in parallel. Finally, the resource conflict level within the window drops to 0, and all tasks are completed within the window period.

[0081] V. Idle Detection and Task Migration:

[0082] During the test execution, the resource scheduling engine's idle monitoring module continuously calculates the continuous idle time of each channel's independent resources. The idle timer for each independent test resource runs independently.

[0083] Assuming that after window W2 is completed, the main controller detects that the balancing simulation module of channel 3 has been idle for 60ms consecutively between 100ms and 160ms, exceeding the preset idle threshold of 50ms, triggering the task migration mechanism. The idle monitoring module filters non-critical tasks from the waiting queue of channel 4, such as the "data reporting" task of channel 4. Upon detection, the idle balancing simulation module of channel 3 has no resource conflict with this task, and the CPU of channel 3 is also idle. Therefore, the resource scheduling engine migrates the "data reporting" task from the W4 window of channel 4 (originally planned to execute between 150-160ms) to the 100-110ms idle period of channel 3. After the migration, the idle period of channel 3 is effectively utilized, the load on the W4 window of channel 4 is reduced, and the overall test time is shortened.

[0084] VI. Parallel Data Processing:

[0085] Each channel integrates an edge computing unit within its controller FPGA. During testing, the edge computing unit performs local preprocessing on the acquired raw data: for example, calculating the effective value of the voltage signal, performing FFT harmonic analysis on the current waveform (extracting the 1st, 3rd, and 5th harmonics), and performing median filtering on the temperature data. After preprocessing, each channel only uploads key data (such as protection delay time, fault codes, and abnormal event records), reducing the amount of uploaded data compared to the original sampled data.

[0086] The real-time controller uploads compressed and packaged key data from each channel to the cloud server every 10ms via Ethernet. Each data point includes a channel ID (e.g., CH1), an absolute timestamp (1ms resolution), and hardware calibration coefficients. This data is synchronously saved to a local solid-state drive, supporting millisecond-level fault playback.

[0087] In summary, this embodiment achieves high efficiency, high precision, and high traceability in BMS testing through multi-channel parallel architecture, hardware-level synchronization, DAG scheduling, time window partitioning, task migration, and edge computing.

[0088] This embodiment provides a testing method for a battery management system, such as... Figure 5 As shown, Figure 5 This is a flowchart illustrating a test method for a battery management system according to an embodiment of this application, including the following steps:

[0089] Step S502: Parse the test script to obtain test tasks, wherein the test tasks are used for test operations on different battery management systems;

[0090] Step S504: Construct a directed acyclic graph of the test task;

[0091] Step S506: Allocate shared test resources of the shared resource pool to multiple test channels according to the directed acyclic graph and the resource occupancy status of the shared resource pool;

[0092] Step S508: Based on the allocated shared test resources and the channel test resources of the multiple test channels, the test operations corresponding to the test task are executed in parallel.

[0093] The above steps involve first parsing the test script to obtain the test tasks; second, constructing a directed acyclic graph (DAG) of the test tasks; then, allocating shared test resources from the shared resource pool to multiple test channels based on the DAG and the resource occupancy status of the shared resource pool; finally, executing the test operations corresponding to the test tasks in parallel based on the allocated shared test resources and the channel test resources of each of the multiple test channels. This method automatically decomposes, schedules, and executes test tasks, effectively solving the resource contention problem in multi-channel parallel testing and significantly improving the automation level and efficiency of BMS testing.

[0094] Optionally, in the above embodiments, the battery management system testing method is applied to a battery management system testing system, which includes multiple independent test channels, each test channel corresponding to channel test resources, wherein the test resources represent the testing capabilities provided by the hardware device for testing the battery management system; a shared resource pool, including shared test resources for use by the multiple test channels; a virtual machine, used to compile test scripts into intermediate bytecode, so that the control center can parse the intermediate bytecode to obtain test tasks, wherein the test tasks are used for test operations on different battery management systems; the control center includes a resource scheduling engine, which is used to construct a directed acyclic graph of the test tasks and allocate the shared test resources according to the directed acyclic graph and the resource occupancy status of the shared resource pool; the control center also includes a master controller and a slave controller corresponding to each test channel, the master controller being used to generate a standard time for the hardware clock and send a broadcast signal to the slave controller based on the standard time, so that each test channel can execute the test operations corresponding to the test tasks in parallel based on the allocated shared test resources and the channel test resources.

[0095] In one exemplary embodiment, the master controller further includes a crystal oscillator and a clock distribution circuit. The output terminal of the crystal oscillator is connected to the input terminal of the clock distribution circuit to generate the standard time and send a broadcast signal to the slave controller based on the standard time. This includes: converting the original clock signal generated by the crystal oscillator into the standard time and distributing the standard time to the slave controller through the low-voltage differential signal bus; generating a synchronization trigger instruction based on the standard time and sending the synchronization trigger instruction to the slave controller through the broadcast signal, wherein the synchronization trigger instruction is used to instruct the multiple test channels to start testing simultaneously.

[0096] In an exemplary embodiment, sending a broadcast signal to the slave controller includes: acquiring a low-voltage differential signal broadcast frame, wherein the frame structure of the broadcast frame includes a frame header field, an instruction code field, a parameter field, and a check field; the frame header field includes a unique broadcast identifier; the instruction code field includes a synchronization trigger instruction, a parameter configuration instruction, and a start / stop control instruction; and the parameter field includes test parameters corresponding to the parameter configuration instruction; sending the broadcast frame to the slave controller, so that after receiving the broadcast frame, the slave controller verifies the broadcast frame based on the check field, and after passing the verification, controls the hardware device in each test channel to perform the test operation according to the instruction code field and the parameter field.

[0097] In one exemplary embodiment, verifying the broadcast frame includes: after receiving the broadcast frame, performing a cyclic redundancy check on the verification field of the broadcast frame to determine the integrity of the broadcast frame; if the verification is successful, executing the instruction obtained by parsing the broadcast frame; if the verification fails, sending a retransmission request signal to the master controller to cause the master controller to retransmit the broadcast frame.

[0098] In an exemplary embodiment, constructing a directed acyclic graph (DAG) of the test task includes: decomposing the test task into multiple indivisible atomic tasks, creating a task node corresponding to each atomic task, wherein the attributes of the task node include task identifier, execution time, required resource list, and priority; determining initial directed edges of the DAG based on the constraint relationships between the multiple atomic tasks, wherein the initial directed edges are used to indicate the execution order between the task nodes, and the execution order satisfies the constraint relationships; performing cycle dependency detection on the initial graph structure formed by the task nodes and the initial directed edges to obtain a detection result; if the detection result indicates that there is no cycle dependency between the task nodes, obtaining the DAG based on the initial graph structure; if the detection result indicates that there is a cycle dependency between the task nodes, adjusting the initial directed edges of the initial graph structure based on the constraint relationships to obtain an adjusted graph structure formed by the task nodes and the adjusted directed edges, and determining the DAG based on the adjusted graph structure, wherein there is no cycle dependency between the task nodes in the adjusted graph structure.

[0099] In an exemplary embodiment, determining the initial directed edges of the directed acyclic graph based on the constraint relationships between the plurality of atomic tasks includes: determining the initial directed edges of the directed acyclic graph based on the logical dependencies between the plurality of atomic tasks and the mutual exclusion relationships arising from the plurality of atomic tasks requesting the same shared test resource, wherein the constraint relationships include the logical dependencies and the mutual exclusion relationships.

[0100] In an exemplary embodiment, allocating the shared test resources based on the directed acyclic graph and the resource occupancy status of the shared resource pool includes: performing topological sorting on the task nodes of the directed acyclic graph to obtain a task node execution sequence; determining a set of tasks that can be executed in parallel based on the task node execution sequence; performing resource conflict detection on atomic tasks in the set of tasks that can be executed in parallel, and determining a resource conflict if the resource lists required by two or more atomic tasks include the same shared test resource; and allocating shared test resources to the atomic tasks with resource conflicts based on the priority of the atomic tasks with resource conflicts and the real-time occupancy status of each shared test resource in the shared resource pool.

[0101] In one exemplary embodiment, allocating shared test resources to the atomic tasks with resource conflicts includes: allocating the shared test resources to the atomic task with the highest priority among the atomic tasks with resource conflicts; and adding the atomic tasks other than the atomic task with the highest priority among the atomic tasks with resource conflicts to the waiting queue in descending order of priority.

[0102] In one exemplary embodiment, the method further includes: dividing the total test duration into multiple consecutive time windows based on the execution time of the atomic tasks in the directed acyclic graph; and assigning the multiple atomic tasks to the corresponding time windows, wherein the atomic tasks in the set of tasks that can be executed in parallel are assigned to the same time window for parallel execution.

[0103] In one exemplary embodiment, the method further includes: establishing a resource request table for atomic tasks allocated to the same time window, the resource request table being used to record the type of shared test resource requested by each atomic task and the scheduled execution time; traversing the atomic tasks in the resource request table in descending order of priority, allocating the requested shared test resource to the first atomic task, and marking the allocated shared test resource as occupied, wherein the first atomic task is the currently traversed atomic task; and adjusting the execution time of the second atomic task in the current time window, or allocating the second atomic task to the next time window, if the shared test resource requested by the second atomic task in the resource request table is already occupied.

[0104] In one exemplary embodiment, the method further includes: monitoring a target test channel and determining idle test resources from the target test channel, wherein the idle test resources represent test resources with a continuous idle duration greater than a preset duration; obtaining a target atomic task to be executed from the waiting queue of other test channels, wherein the other test channels are channels other than the target test channel among the plurality of test channels, and the task type of the target atomic task to be executed is a task type supported by the idle test resources; and migrating the target atomic task to be executed to the target test channel to execute the atomic task to be executed through the idle test resources.

[0105] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods according to the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal device (which may be a mobile phone, computer, server, or network device, etc.) to execute the methods of the various embodiments of this application.

[0106] Embodiments of this application also provide a storage medium including a stored program, wherein the program executes any of the methods described above when it is run.

[0107] Optionally, in this embodiment, the storage medium may be configured to store program code for performing the following steps:

[0108] S1, parse the test script to obtain the test task, wherein the test task is used for test operations on different battery management systems;

[0109] S2, Construct a directed acyclic graph of the test task;

[0110] S3, allocate shared test resources of the shared resource pool to multiple test channels according to the directed acyclic graph and the resource occupancy status of the shared resource pool;

[0111] S4, based on the allocated shared test resources and the channel test resources of the multiple test channels, execute the test operations corresponding to the test task in parallel.

[0112] Embodiments of this application also provide an electronic device including a memory and a processor, wherein the memory stores a computer program and the processor is configured to run the computer program to perform the steps in any of the above method embodiments.

[0113] Optionally, the electronic device may further include a transmission device and an input / output device, wherein the transmission device is connected to the processor and the input / output device is connected to the processor.

[0114] Optionally, in this embodiment, the processor can be configured to perform the following steps via a computer program:

[0115] S1, parse the test script to obtain the test task, wherein the test task is used for test operations on different battery management systems;

[0116] S2, Construct a directed acyclic graph of the test task;

[0117] S3, allocate shared test resources of the shared resource pool to multiple test channels according to the directed acyclic graph and the resource occupancy status of the shared resource pool;

[0118] S4, based on the allocated shared test resources and the channel test resources of the multiple test channels, execute the test operations corresponding to the test task in parallel.

[0119] Optionally, in this embodiment, the storage medium may include, but is not limited to, various media capable of storing program code, such as USB flash drives, read-only memory (ROM), random access memory (RAM), portable hard drives, magnetic disks, or optical disks.

[0120] Optionally, embodiments of this application also provide a computer program product, which includes a computer program that, when executed by a processor, implements the steps in any of the above method embodiments.

[0121] Optionally, embodiments of this application also provide another computer program product, including a non-volatile computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps in any of the above method embodiments.

[0122] Optionally, embodiments of this application also provide a computer program that includes computer instructions stored in a computer-readable storage medium; a processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the steps in any of the above method embodiments.

[0123] Optionally, specific examples in this embodiment can refer to the examples described in the above embodiments and optional implementations, and will not be repeated here.

[0124] Obviously, those skilled in the art should understand that the modules or steps of this application described above can be implemented using general-purpose computing devices. They can be centralized on a single computing device or distributed across a network of multiple computing devices. Optionally, they can be implemented using computer-executable program code, thereby storing them in a storage device for execution by a computing device. In some cases, the steps shown or described can be performed in a different order than those presented here, or they can be fabricated as separate integrated circuits, or multiple modules or steps can be fabricated as a single integrated circuit. Thus, this application is not limited to any particular hardware and software combination.

[0125] The above description is only a preferred embodiment of this application. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. A test system for a battery management system, characterized in that, include: Multiple independent test channels, each with its own channel test resources, where test resources represent the test capabilities provided by the hardware device used to test the battery management system; The shared resource pool includes shared test resources used by the multiple test channels. A virtual machine is used to compile test scripts into intermediate bytecode, so that the control center can parse the intermediate bytecode to obtain test tasks, wherein the test tasks are used for test operations on different battery management systems; The control center includes a resource scheduling engine, which is used to construct a directed acyclic graph of the test tasks and allocate the shared test resources according to the directed acyclic graph and the resource occupancy status of the shared resource pool. The control center also includes a master controller and a slave controller corresponding to each test channel. The master controller is used to generate a standard time for the hardware clock and send a broadcast signal to the slave controller based on the standard time, so that each test channel can execute the test operation corresponding to the test task in parallel based on the allocated shared test resources and the channel test resources.

2. The test system for the battery management system according to claim 1, characterized in that, The master controller is connected to the slave controllers via a low-voltage differential signal bus to form a bus structure. The low-voltage differential signal transmitting end of the master controller is connected to the low-voltage differential signal receiving end of the slave controller. The master controller sends the broadcast signal to the slave controllers via the low-voltage differential signal bus.

3. The test system for the battery management system according to claim 2, characterized in that, The main controller further includes a crystal oscillator and a clock distribution circuit. The output of the crystal oscillator is connected to the input of the clock distribution circuit. The main controller is also used to generate the standard time in the following manner and send a broadcast signal to the slave controller based on the standard time: The original clock signal generated by the crystal oscillator is converted into the standard time, and the standard time is distributed to the slave controller through the low-voltage differential signal bus; A synchronization trigger command is generated based on the standard time, and the synchronization trigger command is sent to the slave controller via the broadcast signal. The synchronization trigger command is used to instruct the multiple test channels to start testing simultaneously.

4. The test system for the battery management system according to claim 2, characterized in that, The master controller is also configured to send broadcast signals to the slave controller in the following manner: Acquire a low-voltage differential signal broadcast frame, wherein the frame structure of the broadcast frame includes a frame header field, an instruction code field, a parameter field, and a check field. The frame header field includes a unique broadcast identifier. The instruction code field includes a synchronization trigger instruction, a parameter configuration instruction, and a start / stop control instruction. The parameter field includes test parameters corresponding to the parameter configuration instruction. The broadcast frame is sent to the slave controller, so that after receiving the broadcast frame, the slave controller verifies the broadcast frame based on the verification field, and after the verification is successful, controls the hardware device in each test channel to perform the test operation according to the instruction code field and the parameter field.

5. The test system for the battery management system according to claim 4, characterized in that, The slave controller is also used to verify the broadcast frame in the following manner: Upon receiving the broadcast frame, a cyclic redundancy check is performed on the check field of the broadcast frame to determine the integrity of the broadcast frame; If the verification is successful, execute the instructions obtained by parsing the broadcast frame; If the verification fails, a retransmission request signal is sent to the main controller so that the main controller retransmits the broadcast frame.

6. The test system for the battery management system according to claim 2, characterized in that, The resource scheduling engine is used to construct the directed acyclic graph of the test task in the following manner: The test task is broken down into multiple indivisible atomic tasks, and a task node is created for each atomic task. The attributes of the task node include task identifier, execution time, required resource list and priority. The initial directed edges of the directed acyclic graph are determined based on the constraint relationships between the multiple atomic tasks. The initial directed edges are used to indicate the execution order between the task nodes, and the execution order satisfies the constraint relationships. Cyclic dependency detection is performed on the initial graph structure formed by the task nodes and the initial directed edges to obtain the detection results; If the detection result indicates that there is no cyclic dependency between the task nodes, the directed acyclic graph is obtained based on the initial graph structure. When the detection result indicates that there is a cyclic dependency between the task nodes, the initial directed edges of the initial graph structure are adjusted based on the constraint relationship to obtain the adjusted graph structure formed by the task nodes and the adjusted directed edges. The directed acyclic graph is determined according to the adjusted graph structure, wherein there is no cyclic dependency between the task nodes in the adjusted graph structure.

7. The test system for the battery management system according to claim 6, characterized in that, Determining the initial directed edges of the directed acyclic graph based on the constraints between the multiple atomic tasks includes: Based on the logical dependencies between the multiple atomic tasks and the mutual exclusion relationships arising from the multiple atomic tasks requesting the same shared test resource, the initial directed edges of the directed acyclic graph are determined, wherein the constraint relationships include the logical dependencies and the mutual exclusion relationships.

8. The test system for the battery management system according to claim 6, characterized in that, The resource scheduling engine is used to allocate the shared test resources based on the directed acyclic graph and the resource occupancy status of the shared resource pool in the following manner: Perform topological sorting on the task nodes of the directed acyclic graph to obtain the task node execution sequence; The set of tasks that can be executed in parallel is determined based on the execution sequence of the task nodes; Resource conflict detection is performed on atomic tasks in the set of tasks that can be executed in parallel. If the resource lists required by two or more atomic tasks include the same shared test resource, it is determined to be a resource conflict. Based on the priority of the atomic tasks with resource conflicts and the real-time occupancy status of each shared test resource in the shared resource pool, shared test resources are allocated to the atomic tasks with resource conflicts.

9. The test system for the battery management system according to claim 8, characterized in that, The resource scheduling engine is used to allocate shared test resources to the atomic tasks with resource conflicts in the following manner: The shared test resource is allocated to the highest priority atomic task among the atomic tasks with resource conflicts; Atomic tasks that are in conflict with resources, excluding the highest-priority atomic task, are added to the waiting queue in descending order of priority.

10. The test system for the battery management system according to claim 9, characterized in that, The resource scheduling engine also includes a time window scheduling module, which is used for: Based on the execution time of the atomic tasks in the directed acyclic graph, the total test duration is divided into multiple consecutive time windows; The multiple atomic tasks are assigned to corresponding time windows, wherein the atomic tasks in the set of tasks that can be executed in parallel are assigned to the same time window for parallel execution.

11. The test system for the battery management system according to claim 10, characterized in that, The time window scheduling module is also used for: A resource request table is established for atomic tasks assigned to the same time window. The resource request table is used to record the type of shared test resources requested by each atomic task and the scheduled execution time. The atomic tasks in the resource request table are traversed in descending order of priority. The requested shared test resources are allocated to the first atomic task, and the allocated shared test resources are marked as occupied. The first atomic task is the atomic task currently being traversed. If the shared test resource requested by the second atomic task in the resource request table is already occupied, adjust the execution time of the second atomic task within the current time window, or allocate the second atomic task to the next time window.

12. The test system for the battery management system according to claim 1, characterized in that, The resource scheduling engine also includes a monitoring module, which is used for: The target test channel is monitored, and idle test resources are determined from the target test channel, wherein the idle test resources refer to test resources with a continuous idle duration greater than a preset duration; Obtain the target atomic task to be executed from the waiting queue of other test channels, wherein the other test channels are channels other than the target test channel among the plurality of test channels, and the task type of the target atomic task to be executed is the task type supported by the idle test resources; The target atomic task to be executed is migrated to the target test channel so that the target atomic task can be executed using the idle test resources.

13. The test system for the battery management system according to claim 1, characterized in that, Each test channel's channel test resources include at least the test capabilities provided by an adjustable power supply, bidirectional load, data acquisition unit, daisy-chain simulator, and fault injection matrix, and each test channel is isolated from other test channels.

14. The test system for the battery management system according to claim 1, characterized in that, The shared test resources include at least the testing capabilities provided by a high-voltage insulation tester and an insulation impedance simulation array; the high-voltage insulation tester is connected to the plurality of test channels respectively through a first switching array, and the insulation impedance simulation array is connected to the plurality of test channels respectively through a second switching array; the control terminals of the first switching array and the second switching array are both connected to the control center; the control center is also used to allocate the shared test resources by controlling the first switching array and the second switching array.

15. A test method for a battery management system, characterized in that, include: The test script is parsed to obtain the test task, wherein the test task is used to test different battery management systems; Construct a directed acyclic graph of the test task; Based on the directed acyclic graph and the resource occupancy status of the shared resource pool, the shared test resources of the shared resource pool are allocated to multiple test channels; The test operations corresponding to the test tasks are executed in parallel based on the allocated shared test resources and the channel test resources of the multiple test channels.

16. A computer-readable storage medium, characterized in that, The computer-readable storage medium includes a stored program, wherein the program, when executed, performs the method of claim 15.

17. An electronic device comprising a memory and a processor, characterized in that, The memory stores a computer program, and the processor is configured to execute the method of claim 15 through the computer program.

18. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method of claim 15.

Images