A BMS multi-thread parallel FCT test software system and method

Abstract

The application discloses a BMS multithreading parallel FCT test software system and method, and belongs to the technical field of BMS testing. The system comprises a visual BMS test scheme editing module, a DAG task dependency graph construction module, a parallel task scheduling engine, a dynamic thread pool, a BMS communication hardware resource management module, a thread safety message queue data collection module and a BMS special abnormal interlocking protection module. The DAG task dependency graph construction module constructs a directed acyclic graph topology according to task time sequence dependency, and distinguishes between strong time sequence tasks and parallel tasks; the scheduling engine enables the strong time sequence tasks to be executed in series and the parallel tasks to be executed in parallel through the dynamic thread pool; the communication hardware resource management module controls and manages the resource locking and message buffering of a communication bus and test instruments, and avoids concurrent message conflicts; and the data collection module uniformly collects sampling data and test results of each thread and stores them in order, shortens the test period, and realizes code-free model adaptation and hardware interlocking protection.

Description

Technical Field

[0001] This invention belongs to the field of automated FCT functional testing technology for mass production of energy storage BMS, power battery BMS, and portable lithium battery protection boards. Specifically, it relates to a high-speed parallel multi-threaded test software system and method based on C# WinForms platform using DAG (Directed Acyclic Graph) scheduling, which is particularly suitable for rapid functional testing scenarios in BMS mass production lines. Background Technology

[0002] In the mass production FCT (Functional Circuit Test) testing of BMS (Battery Management System), a large number of test items need to be completed, including dynamic and static power consumption testing, single cell voltage sampling, temperature sampling, current sampling, equalization circuit testing, testing of each communication loop, functional peripheral IO signal testing, multi-level overvoltage / undervoltage / overcurrent / overtemperature protection testing, and firmware version verification.

[0003] Existing BMS-specific FCT testing software generally adopts a single-threaded serial execution architecture, which has the following drawbacks: Test tasks are executed serially, resulting in long test cycles: all BMS test items are executed sequentially, and the test instruments and communication channels are idle for a long time during the voltage stabilization waiting, protection condition trigger delay, and communication response waiting phases. Due to the large number of BMS test items, the serial mode test is time-consuming, which seriously restricts the production line's UPH (Units Per Hour).

[0004] Many independent BMS test tasks cannot be parallelized: tasks such as multi-channel temperature acquisition, multi-channel voltage sampling, static current detection, and indicator status detection do not have timing dependencies, but traditional software can only run them serially, resulting in serious time waste.

[0005] Fixed processes: Fixed testing processes correspond to fixed products. Adapting to different products requires extensive code modifications, resulting in high maintenance costs and long changeover cycles.

[0006] Lack of flexible fault tolerance mechanism: The entire process is terminated directly when a single test item fails, lacking logic such as retry, skip, and branch judgment, resulting in a low production line pass rate.

[0007] The lack of an abnormal linkage protection mechanism for BMS business adaptation: If the simulated battery cannot be cut off and the fault injection cannot be stopped in time when an abnormality occurs during testing, it is very easy to cause overvoltage and overcurrent damage to the BMS under test, which poses a significant risk of product damage.

[0008] In summary, existing BMS FCT testing software suffers from low serial execution efficiency, poor scalability, and weak fault tolerance. Therefore, there is an urgent need for a technical solution that can decompose the scattered test items, device interactions, data acquisition, result judgment, log storage, and defect rework processes of BMS mass production FCT into independent task nodes by introducing a DAG (Directed Acyclic Graph) task scheduling mechanism. This solution can then implement complex testing logic such as parallelism, serialism, branching, skipping, and retrying through configurable dependencies, thereby adapting to the differentiated testing processes of different BMS models and improving FCT testing efficiency, stability, and scalability. Summary of the Invention

[0009] To address the aforementioned shortcomings of existing technologies, the present invention aims to provide a multi-threaded parallel high-speed test software system and method for BMS FCT testing, thereby solving the problems of low serial execution efficiency, bus concurrency conflicts, difficult timing control, difficult data traceability, weak fault tolerance, and high cost of model replacement and adaptation in traditional BMS FCT test software.

[0010] This solves the problems of traditional BMS FCT software, such as single-threaded serial execution, long test cycles, and low production line testing efficiency.

[0011] This solution addresses issues such as message preemption, command conflicts, and data confusion in multi-threaded concurrent scenarios using communication buses like CAN, CAN FD, and RS485; it resolves challenges in intelligently managing timing dependencies in BMS test tasks, disrupted timing sequences in concurrent test processes, and test misjudgments; it addresses the problems of generating large amounts of BMS sampling data during parallel testing, unordered communication messages, and difficulties in unified storage and traceability; it achieves abnormal isolation of BMS test tasks, ensuring that a single test task failure does not interrupt all tests, while also supporting BMS overload interlocking hardware protection; and it supports visual configuration of test processes for various BMS models, enabling rapid adaptation to energy storage, power, and low-power BMS replacement testing without modifying underlying code.

[0012] To achieve the above objectives, the present invention adopts the following technical solution.

[0013] A BMS multi-threaded parallel FCT testing software system includes: a visual BMS test plan editing module, a test plan parsing module, a DAG task dependency graph construction module, a parallel task scheduling engine, a dynamic thread pool, a BMS communication hardware resource management module, a thread-safe message queue data collection module, and a BMS-specific exception interlock protection module. The DAG task dependency graph construction module constructs a directed acyclic graph task topology based on the temporal dependencies between BMS test tasks, and classifies the BMS test tasks into strongly temporal tasks with temporal dependencies and mutually independent parallel tasks. The parallel task scheduling engine traverses the directed acyclic graph task topology, enabling the strongly sequential tasks to be executed serially, and enabling the mutually independent parallel tasks to be executed in parallel by multiple threads through the dynamic thread pool. The BMS communication hardware resource management module performs resource lock control and message buffering before parallel tasks access the BMS communication bus or test instruments to avoid message conflicts caused by multi-threaded concurrent access. The thread-safe message queue data collection module uniformly receives the BMS sampling data, communication messages and test results output by each worker thread, and stores them in an orderly manner.

[0014] As a further preferred embodiment of the above implementation: the BMS communication hardware resource management module sets up a unified communication proxy layer and an exclusive mutex lock, so that only a single thread is allowed to issue instructions on the same communication bus at any given time, enabling different communication channels and independent test instruments to support parallel access, and has a built-in message buffer queue to ensure the orderly matching of BMS sent and received messages; the DAG task dependency graph construction module determines BMS power-on wake-up, fault condition injection, and protection action verification as strongly time-sequential tasks that must be executed serially, and determines multi-channel voltage sampling and multi-channel temperature acquisition as independent tasks that can be scheduled in parallel; the dynamic thread pool supports configuring the maximum number of concurrent threads and dynamically allocates reused worker threads according to the number of ready tasks.

[0015] As a further preferred embodiment of the above implementation: the visual BMS test scheme editing module has built-in BMS-specific test components for individual unit voltage acquisition, NTC temperature detection, equalization testing, multi-level protection verification, fault code reading, and SOC accuracy verification. It supports drag-and-drop editing of test processes, graphical configuration of task dependencies, and uses JSON templates combined with memory caching and local JSON dual backup storage configuration. It uses a double-buffered drawing mode to render the DAG graph, uses asynchronous progress push combined with UI thread marshaling mechanism to isolate the scheduling thread and UI thread, and implements hierarchical permission control based on local role configuration files, so it can adapt to different models of BMS without modifying the underlying code.

[0016] As a further preferred embodiment of the above implementation: each worker thread is only responsible for executing the test and pushing the test data to the thread-safe message queue data collection module, and the main thread consumes the messages uniformly to complete the time-series storage of BMS unit voltage, temperature, fault codes and original communication messages, so as to avoid data disorder and loss caused by multi-threaded concurrent writing.

[0017] As a further preferred embodiment of the above implementation: each parallel BMS test task is equipped with an independent timeout monitoring unit, which supports single-task abnormal isolation and retry, and the failure of a single task does not block the other parallel test tasks; when the BMS dedicated abnormal interlock protection module detects high-risk abnormalities such as overvoltage, overcurrent, and communication loss, it outputs a control signal to link the battery simulator and fault injection unit to perform a reset and cut off the excitation signal to prevent damage to the BMS hardware under test.

[0018] As a further preferred embodiment of the above implementation: the parallel task scheduling engine performs scheduling according to the five-level hierarchical DAG topology execution logic of initialization serial, multiple sets of parallel tests, conditional branch judgment, deep protection test, and archiving and closing, and distinguishes between key nodes and ordinary nodes to perform intelligent fault tolerance, including automatic retry for sampling out of tolerance, retesting for minor anomalies, circuit breaking and archiving for serious anomalies, and automatically skipping time-consuming high-voltage protection tests when basic tests fail.

[0019] As a further preferred embodiment of the above implementation: the system supports the import and export of test plans, is applicable to the FCT mass production test of multiple products such as power battery BMS, energy storage BMS and portable lithium battery protection boards, and automatically summarizes test item data to generate test reports, supports statistical analysis of defective data, and reserves a data docking interface for MES system to realize digital traceability management of mass production test data.

[0020] In addition, a BMS multi-threaded parallel FCT testing method is disclosed, including the following steps: Construct a directed acyclic graph task topology for BMS test tasks, and classify the BMS test tasks into strongly time-series tasks with temporal dependencies and mutually independent parallel tasks. Traverse the directed acyclic graph task topology, execute the strongly sequential tasks serially, and allocate the mutually independent parallel tasks to a dynamic thread pool for multi-threaded parallel execution. Before parallel tasks access the BMS communication bus or test instrument, resource locks are requested through the communication hardware resource management module to queue up tasks that access the same communication bus or the same test instrument, and to allow tasks that access different hardware resources to be executed in parallel. The BMS sampling data, communication messages, and test results obtained from each task execution are pushed to a thread-safe message queue for unified collection and orderly storage.

[0021] As a further preferred embodiment of the above implementation: when a high-risk anomaly such as overvoltage, overcurrent or communication failure is detected, the battery simulator and fault injection unit are reset and the excitation signal is cut off to perform hardware interlock protection for the test task in a high-risk abnormal state.

[0022] As a further preferred embodiment of the above implementation: scheduling is performed according to a five-level hierarchical DAG topology execution logic, which includes initialization serial, multiple parallel tests, conditional branch judgment, deep protection test, and archiving. Intelligent fault tolerance is performed by distinguishing between critical nodes and ordinary nodes. Specifically, automatic retry is performed when sampling exceeds the tolerance, minor anomalies are retested, severe anomalies trigger circuit breaking and jump to archiving, and time-consuming high-voltage protection tests are automatically skipped when basic tests fail. Furthermore, the test process and task dependencies are configured through a visual interface by dragging and dropping to generate JSON templates, so that different models of BMS can be adapted without modifying the underlying code.

[0023] In addition, a computer-readable storage medium is disclosed, on which a computer program is stored, which, when executed by a processor, implements the above-described BMS multi-threaded parallel FCT test method.

[0024] The outstanding and beneficial technical effects of this invention compared to the prior art are: 1. Significantly improves the testing efficiency of the BMS production line: the parallel execution of dependency-free sampling tasks greatly reduces waiting time, effectively shortens the testing cycle and improves the production line UPH compared to traditional serial BMS testing software; 2. Solve the problem of concurrent conflicts on the BMS bus: By using communication resource proxy and message buffering mechanisms, avoid message disorder and misjudgment of protection functions caused by multiple threads preempting the CAN / 485 bus; 3. Strictly adapts to BMS test timing logic: Relying on DAG topology scheduling, it ensures the orderly execution of highly time-sensitive tasks such as power-on, fault injection, and protection verification, while taking into account both parallel acceleration and test security; 4. Complete, orderly and traceable BMS test data: A unified message queue collects voltage, temperature, fault codes and original communication messages, which facilitates R&D in locating BMS sampling anomalies and protection logic defects; 5. Graded safety protection reduces the risk of damage to the BMS under test: high-risk anomalies automatically trigger the battery simulator and fault injection unit to reset, adapting to long-term stable operation in mass production; 6. Quickly adapt to multiple BMS models: Built-in dedicated BMS testing components and a visual configuration process mean that new models do not require modification of the underlying code, shortening the production line changeover and adaptation cycle. Attached Figure Description

[0025] Figure 1 This is a block diagram of the overall architecture of the testing software described in this invention; Figure 2 This is a flowchart of the parallel scheduling workflow for BMS testing based on DAG task topology of the test software described in this invention.

[0026] Wherein: the arrows indicate the direction of data flow and control flow; the modules shown in the accompanying drawings are used to clearly illustrate the technical solution of the present invention and do not constitute a limitation on the scope of protection of the present invention. Detailed Implementation

[0027] The present invention will now be described in further detail with reference to the accompanying drawings and specific embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the invention and are not intended to limit the scope of protection of the invention.

[0028] This embodiment provides a BMS multi-threaded parallel FCT testing software system, which is implemented based on the C# WinForms platform and adopts a five-layer fully decoupled layered modular architecture. For example... Figure 1 As shown, the main body of the system, from bottom to top, includes: a data storage and interface layer, a device and protocol interaction layer, an FCT business logic layer, a DAG task scheduling core layer, and a human-computer interaction UI configuration and visualization layer. Each layer interacts with the others through standardized interfaces, achieving a loosely coupled and highly cohesive software design, thereby ensuring high real-time performance, high stability, and high scalability in mass production scenarios.

[0029] I. Human-Computer Interaction UI Configuration and Visualization Layer This layer is geared towards process and production line operators, providing functions such as machine selection, visual configuration of testing procedures, DAG topology rendering, real-time monitoring of the testing process, and access control. Specifically: This implementation uses a lightweight WinForms GDI+ drawing tool to render DAG graphs, employing a double-buffered drawing mode to effectively prevent interface flickering caused by high-frequency state refreshes of parallel tasks. All configuration parameters are backed up using both memory caching and local JSON, ensuring that parameters are not lost and can be recovered after power outages or abnormal exits. UI updates utilize asynchronous progress pushing combined with a UI thread marshaling mechanism, strictly isolating the background scheduling thread and the UI thread to resolve WinForms interface freezing issues. The permission system is implemented based on local role configuration files, enabling hierarchical control without the need for a database.

[0030] II. Core Layer of DAG Task Scheduling This layer is the core layer of this invention, responsible for tasks such as task parsing, dependency verification, scheduling engine, task status management, fault tolerance mechanism, parallel / serial scheduling, and branch condition judgment. It is based on the WinForms platform, does not rely on a third-party scheduling framework, and uses a self-developed lightweight DAG engine. The specific design is as follows: Topological sorting is achieved using adjacency list addition degree statistics, with a time complexity of O(n), supporting millisecond-level parsing of hundreds of task nodes; parallel scheduling is implemented based on the .NET ThreadPool thread pool, with controllable maximum concurrency (default 8 threads, configurable) to prevent device overload; a built-in global CancellationTokenSource supports emergency termination and resource reclamation; task states are stored using a thread-safe dictionary to prevent multi-threaded state overwriting anomalies; a custom static resource lock for the device is used to mark mutually exclusive tasks and automatically queue them for execution; breakpoint resume is supported, and the set of completed tasks is recorded in memory, automatically skipping executed nodes after restart.

[0031] This core layer boasts outstanding advantages such as no third-party dependencies, millisecond-level scheduling, smooth UI, and perfect adaptation to the interaction logic of production line testing equipment.

[0032] Specifically, in this embodiment, each BMS test task is described as a task node object in the DAG task topology. The task node object includes at least a unique task identifier, task category, a list of prerequisites, a required exclusive resource identifier, a timeout threshold, a maximum number of retries, decision parameters, and a task status field. Among them, the task category is used to mark the task as a strongly time-series task or a parallel task; the list of prerequisites records the set of unique task identifiers of all parent tasks that must be completed before the task is executed; the required exclusive resource identifier records the communication bus channel or test instrument that the task needs to exclusively occupy during execution; the decision parameters record the upper limit of the threshold, the lower limit of the threshold, and the number of samples used for the task's decision; the task status transitions between pending scheduling, ready, executing, successful execution, and failed execution; the dependencies of all task nodes are stored using an adjacency list, and an in-degree statistics table corresponding to each node is maintained. The in-degree of any task node is equal to the number of parent tasks in its list of prerequisites that have not yet been successfully executed.

[0033] The parallel task scheduling engine executes scheduling according to the following rules: The scheduling engine continuously scans the in-degree statistics table, and identifies task nodes with an in-degree of zero and a pending task status as ready tasks and adds them to the ready queue; strongly sequential tasks in the ready queue are submitted to the global serial execution queue and executed one by one in topological order; parallel tasks in the ready queue are submitted to the dynamic thread pool and executed concurrently by idle worker threads; after any task node executes successfully, the scheduling engine traverses the downstream nodes in the adjacency list with that task node as its predecessor, decrements the in-degree of each downstream node by one, and downstream nodes with an in-degree of zero and all their predecessor tasks executed successfully enter the ready state; after any task node fails to execute, the scheduling engine decides whether to terminate all scheduling or skip its downstream nodes according to the fault tolerance level of that task node; the dynamic thread pool uses semaphores to limit the number of worker threads executing simultaneously to the configurable maximum number of concurrent threads, and worker threads are returned to the thread pool after completing their tasks for reuse by subsequent ready tasks.

[0034] III. FCT Business Logic Layer This layer is the algorithm judgment and data processing layer, realizing the decoupling of scheduling and business, and the decoupling of business and equipment. All test data adopts a sliding window filtering and extreme value elimination algorithm to avoid interference from industrial sites; all judgment thresholds, delay parameters, and sampling times are all configurable; defect codes adopt a unified coding standard, with each type of fault uniquely corresponding to a code, facilitating statistics and rework; the business layer has no thread blocking logic, and all test methods are uniformly encapsulated as Async asynchronous methods, adapting to the DAG asynchronous scheduling model.

[0035] Specifically, the sliding window filtering and extreme value elimination algorithm is executed according to the following rules: For each sampling test item, the working thread continuously collects N sample values ​​according to the sampling period set for the test item to form a sliding window. N is 10 by default and can be configured according to the test item. During filtering, the maximum and minimum values ​​in the window are eliminated, and the arithmetic mean of the remaining sample values ​​is taken to obtain the effective sample value of the test. If the range of the sample values ​​in the window exceeds the fluctuation threshold set for the test item, it is determined that the current window data is affected by industrial site interference, the window data is discarded and re-collected.

[0036] The test judgment rule is as follows: the valid sampled value is compared with the upper and lower thresholds in the judgment parameters of the test item. If the valid sampled value is higher than the upper threshold or lower than the lower threshold, the test item is judged to be unqualified, and the corresponding defect code is recorded according to the unified coding standard. The judgment threshold, delay parameter and sampling number of each test item are configured through the JSON template in the test plan. Adjusting the threshold does not require modifying the program code.

[0037] IV. Device and Protocol Interaction Layer This layer is the software and external hardware device adaptation layer. It is uniformly encapsulated with protocols, including mainstream BMS communication protocols such as CAN2.0, UART, and RS485, and implements standardized message parsing, command encapsulation, and response verification logic. It supports custom protocol configuration and is compatible with commonly used mass-produced FCT equipment such as programmable DC power supplies, electronic loads, high and low temperature chambers, CAN analyzers, and serial port testers.

[0038] V. Data Storage and Interface Layer This layer implements full lifecycle management of test data, responsible for the storage, management, and external integration of test process data, process templates, and log information. It enables full traceability of test data, controllable process versions, and interoperability of mass production data, meeting the needs of industrial mass production traceability and digital management. It includes a local lightweight storage module, a hierarchical log management module, a DAG template version management module, a test report generation module, an MES platform integration module, and a data backup and recovery module.

[0039] VI. Parallel Scheduling Workflow of DAG Combination Figure 2 The complete workflow of the testing software of this invention in BMS mass production FCT testing is as follows: Operators select the BMS model to be tested in the software interface, drag and drop BMS-specific test components, configure test thresholds and protection judgment conditions, and graphically define the prerequisite dependencies of each test task. After the test starts, the test scheme parsing module reads all test nodes and constructs a DAG topology graph for the BMS test task. The parallel task scheduling engine traverses the topology in real time and filters all ready tasks that have completed the prerequisites. The dynamic thread pool allocates idle threads to execute ready tasks. Before accessing the CAN / 485 bus, battery simulator, and fault injection device, the task requests a resource lock through the communication resource proxy. Tasks on the same bus are accessed in a queue, and different hardware resources are scheduled in parallel. After each thread completes voltage, temperature, equalization, protection, and communication tests, it pushes the sampled data, raw messages, and test results to the global message queue. The main thread consumes queue data uniformly, refreshes the interface, persists data storage, and records complete communication logs. The task status is continuously monitored during the test process, and retrying or hardware interlocking protection is executed according to preset strategies when timeouts or data deviations occur. After all tasks are completed, the results of all BMS test items are summarized, a test report is automatically generated, and it is supported to upload to the MES system, completing the entire BMS parallel FCT test.

[0040] Specifically, the resource lock control of the communication hardware resource management module is executed according to the following rules: resource locks are based on independent lock granularity for communication bus channels and test instruments, with each communication bus channel and each test instrument corresponding to an exclusive mutex lock; when a test task needs to access a certain communication bus channel or test instrument, it first applies for the corresponding exclusive mutex lock through the communication resource agent. The task that successfully applies is allowed to issue instructions, while tasks that do not apply for a lock are queued in the corresponding waiting queue; in the event of a task finishing its access, encountering an execution exception, or timing out, all exclusive mutex locks it occupies are forcibly released in the exception handling logic to avoid lock leakage leading to deadlock; tasks accessing different communication bus channels or different test instruments are not constrained by the same exclusive mutex lock and maintain parallel execution.

[0041] The message buffer queue ensures ordered matching of messages according to the following rules: The communication proxy layer assigns an incrementing transaction identifier to each message sending transaction. When sending a command, the transaction identifier and the command are pushed into the acknowledgment queue. When an acknowledgment message is received, a matching item is retrieved from the acknowledgment queue according to the transaction identifier. If a match is found, the acknowledgment item is popped and the acknowledgment data is returned to the initiating task. If a match fails, the acknowledgment message is recorded as an abnormal message in the communication log. If any acknowledgment item fails to find an acknowledgment message after the acknowledgment timeout threshold, the communication proxy layer automatically resends the command. After the number of resends reaches the resend limit, the communication is deemed to have failed and a communication abnormality is reported. The acknowledgment timeout threshold is 500 milliseconds by default, and the resend limit is 2 times by default, both of which can be configured according to the communication channel.

[0042] The data collection rules of the thread-safe message queue data collection module are as follows: Each worker thread encapsulates the test output data into a message object and pushes it into the global concurrent queue. The message object includes at least the task unique identifier, message generation timestamp, data category, sampled value, original communication message, and judgment result fields. The main thread consumes the concurrent queue in a circular dequeue manner, routes the data to the corresponding test item's storage record according to the task unique identifier in the message object, and writes the BMS unit voltage, temperature, fault code, and original communication message into the local database and log file in the order of message generation timestamps. This ensures that the data generated by the parallel tasks restores its true time sequence at the storage level, preventing out-of-order and loss events. The interface refresh is triggered uniformly by the main thread after consuming the message and submitted to the interface for rendering via the UI thread marshaling mechanism.

[0043] VII. BMS Hierarchical Anomaly Isolation and Hardware Interlocking Protection Mechanism This invention equips each parallel test task with independent timeout monitoring and supports a two-level exception handling strategy: Minor anomalies: If the current task fails, it will be retried independently, while other parallel BMS test tasks continue to run, achieving single-task anomaly isolation without interrupting the overall test process; High-risk anomalies (overvoltage, overcurrent, communication failure): Trigger global interlocking, control the battery simulator and fault injection unit to quickly reset, cut off the excitation signal, and prevent damage to the BMS under test.

[0044] This mechanism effectively solves the defects of traditional FCT testing, such as "single-point jamming, full-process blockage, and direct NG of the entire board due to minor errors", and significantly improves the production line pass rate and mass production stability.

[0045] Specifically, anomaly detection and tiered handling are performed according to the following rules: Task timeout is determined when the task execution time exceeds the timeout threshold configured for that task node; sampling error is determined when the filtered valid sample value exceeds the upper or lower threshold of the test item's judgment parameter. Handling minor anomalies involves triggering an independent retry for the task, with the number of retries not exceeding the maximum number of retries configured for that task node (default is 2, configurable per task); other parallel tasks continue execution during the retry period; if the retry still fails, the task is marked as failed and a fault code is recorded. When the task is a regular node, only the task and its downstream nodes are isolated, without affecting the scheduling of other tasks.

[0046] The criteria for determining high-risk anomalies are as follows: the sampled voltage value of a single BMS cell exceeds the overvoltage threshold; the sampled current value exceeds the overcurrent threshold; and all communication transactions on the same communication bus for a preset number of consecutive times are judged as communication failures, i.e., communication is lost. The preset number of times is 3 by default and can be configured according to the communication channel. Meeting any of the above conditions triggers a global interlock: the scheduling engine suspends all ready tasks and stops dispatching new tasks to the dynamic thread pool; the BMS-dedicated anomaly interlock protection module outputs a control signal to reset the battery simulator and cut off the output excitation, reset the fault injection unit and stop fault injection; then, it waits for all hardware resources to read back to a safe state, forcibly archives the completed test data, and ends the current test process.

[0047] 8. Layered Hybrid Scheduling and Intelligent Branch Circuit Breaker This invention innovatively designs a five-level hierarchical DAG topology execution logic, namely, serial initialization, multiple parallel tests, conditional branch decision, deep protection test, and archiving and cleanup, and incorporates a refined intelligent fault-tolerance mechanism: Distinguish between critical nodes and ordinary nodes: critical node failures terminate the process, while ordinary node failures are isolated without blocking the overall process; support automatic retry for sampling out-of-tolerance, retesting for minor anomalies, and direct circuit breaking and jump to archiving for serious anomalies; automatically skip time-consuming low-voltage / high-voltage protection tests when basic tests fail, balancing test accuracy and production line cycle efficiency; achieve refined management of task status, accurately locate faults to single nodes, and solve the problem of traceability in traditional solutions.

[0048] Specifically, the nodes in the five-level hierarchical DAG topology are assigned as follows: the initialization serial layer includes nodes for power-on wake-up, system self-test, and firmware version verification, with system self-test and firmware version verification being independent and executed in parallel; the multi-group parallel test layer includes independent sampling nodes such as individual voltage acquisition, NTC temperature detection, equalization circuit detection, and detection of each communication loop; the conditional branch decision layer determines whether all basic test items of the BMS under test are qualified based on the summary results of the multi-group parallel test layers, and directly jumps to the archiving and closing layer if any are unqualified; the deep protection test layer includes strong timing nodes such as overvoltage protection, undervoltage protection, overcurrent protection, and overtemperature protection verification, which must be executed serially in fault condition injection and protection action verification; and the archiving and closing layer includes nodes for test data summarization, test report generation, and device reset.

[0049] Critical nodes and ordinary nodes are configured by the node attributes in the test plan: power-on wake-up and each protection verification node are configured as critical nodes by default. When a critical node fails, all scheduling is terminated and the process jumps to the archiving and cleanup layer. Sampling nodes are configured as ordinary nodes by default. When an ordinary node fails, only that node and its downstream nodes are isolated. The handling of severe exception circuit breakers is as follows: when the retry count for any task is exhausted and the exception level reaches the preset severity level, the scheduling engine marks that task node and all its downstream nodes as circuit breakers to be skipped, and the control flow jumps directly to the archiving and cleanup layer to ensure the complete archiving of collected data and the safe reset of hardware resources.

[0050] Taking the mass production FCT test of a power battery BMS motherboard as an example, the operator selects the corresponding test plan for the model through a visual interface. The plan includes multiple test nodes such as power-on wake-up, single-cell voltage acquisition, NTC temperature detection, equalization circuit detection, CAN communication loop detection, RS485 communication detection, overvoltage protection, over- and undervoltage protection, overcurrent protection, over-temperature protection, and firmware version verification. The operator connects these nodes into a DAG task topology by dragging and dropping, and sets relevant dependencies: for example, power-on wake-up must be executed first, each sampling task (multi-channel voltage acquisition, multi-channel temperature acquisition) is independent and can be executed in parallel, protection verification tasks must be executed serially after power-on wake-up, and firmware version verification can be performed in parallel during the initialization phase.

[0051] After the test starts, the DAG task dependency graph construction module completes topology sorting and identifies ready tasks based on dependencies; the parallel task scheduling engine allocates independent voltage and temperature sampling tasks to different worker threads in the dynamic thread pool for parallel execution, while scheduling highly time-sequential tasks such as power-on wake-up, fault injection, and protection verification serially; before accessing hardware such as the CAN / 485 bus and battery simulator, the worker threads first apply for resource locks through the communication resource proxy to ensure that only one thread issues instructions on the same bus at the same time, and different hardware resources are accessed in parallel; each thread pushes the sampled data, raw messages, and judgment results to the thread-safe message queue, which is consumed by the main thread and written to the local database and logs.

[0052] During testing, if a voltage sampling task times out, only that task is retried independently, while the remaining parallel tasks continue execution. If high-risk anomalies such as overvoltage or communication failure are detected, the dedicated BMS anomaly interlock protection module immediately triggers a battery simulator reset and cuts off the excitation, protecting the BMS under test from damage. After all nodes have completed execution, the system summarizes the test results, generates a test report, and uploads it to the MES system. Actual testing shows that, compared to traditional fully serial BMS FCT testing software, this embodiment parallelizes independent sampling tasks, significantly shortening the test cycle time and increasing the production line's UPH (upper usage per second). Simultaneously, communication resource locks and hierarchical interlock protection ensure the safety of the test sequence and the safety of the device under test.

[0053] The above embodiments are merely preferred embodiments of the present invention and are not intended to limit the scope of protection of the present invention. Therefore, all equivalent changes made in accordance with the structure, shape, and principle of the present invention should be covered within the scope of protection of the present invention.

Claims

1. A BMS multi-threaded parallel FCT testing software system, characterized in that, include: The system includes a visual BMS test plan editing module, a test plan parsing module, a DAG task dependency graph construction module, a parallel task scheduling engine, a dynamic thread pool, a BMS communication hardware resource management module, a thread-safe message queue data collection module, and a BMS-specific exception interlock protection module. The DAG task dependency graph construction module constructs a directed acyclic graph task topology based on the temporal dependencies between BMS test tasks, and classifies the BMS test tasks into strongly temporal tasks with temporal dependencies and mutually independent parallel tasks. The parallel task scheduling engine traverses the directed acyclic graph task topology, enabling the strongly sequential tasks to be executed serially, and enabling the mutually independent parallel tasks to be executed in parallel by multiple threads through the dynamic thread pool. The BMS communication hardware resource management module performs resource lock control and message buffering before parallel tasks access the BMS communication bus or test instruments to avoid message conflicts caused by multi-threaded concurrent access. The thread-safe message queue data collection module uniformly receives the BMS sampling data, communication messages and test results output by each worker thread, and stores them in an orderly manner.

2. The BMS multi-threaded parallel FCT test software system according to claim 1, characterized in that, The BMS communication hardware resource management module sets up a unified communication proxy layer and exclusive mutex locks, ensuring that only a single thread can issue commands on the same communication bus at any given time. This allows different communication channels and independent test instruments to support parallel access, and a built-in message buffer queue ensures the orderly matching of BMS sent and received messages. The DAG task dependency graph construction module identifies BMS power-on wake-up, fault condition injection, and protection action verification as strongly time-sequential tasks that must be executed serially, while identifying multi-channel voltage sampling and multi-channel temperature acquisition as independent tasks that can be scheduled in parallel. The dynamic thread pool supports configuring a maximum number of concurrent threads and dynamically allocates reused worker threads based on the number of ready tasks.

3. The BMS multi-threaded parallel FCT test software system according to claim 1, characterized in that, The visual BMS test scheme editing module has built-in BMS-specific test components for single-unit voltage acquisition, NTC temperature detection, equalization test, multi-level protection verification, fault code reading, and SOC accuracy verification. It supports drag-and-drop editing of test processes, graphical configuration of task dependencies, and configuration using JSON templates combined with memory caching and local JSON dual backup storage. It uses a double-buffered drawing mode to render the DAG graph, uses asynchronous progress push combined with UI thread marshaling mechanism to isolate the scheduling thread and UI thread, and implements hierarchical permission control based on local role configuration files, so it can be adapted to different BMS models without modifying the underlying code.

4. The BMS multi-threaded parallel FCT test software system according to claim 1, characterized in that, Each worker thread is only responsible for executing the test and pushing the test data to the thread-safe message queue data collection module. The main thread consumes the messages uniformly and completes the time-series storage of BMS unit voltage, temperature, fault codes and original communication messages, avoiding data disorder and loss caused by multi-threaded concurrent writing.

5. The BMS multi-threaded parallel FCT test software system according to claim 4, characterized in that, Each parallel BMS test task is equipped with an independent timeout monitoring unit, supporting single-task exception isolation and retry, and ensuring that a single task failure does not block other parallel test tasks; when the BMS dedicated exception interlock protection module detects high-risk anomalies such as overvoltage, overcurrent, or communication failure, it outputs a control signal to trigger the battery simulator and fault injection unit to perform a reset and cut off the excitation signal to prevent damage to the BMS hardware under test.

6. The BMS multi-threaded parallel FCT test software system according to claim 1, characterized in that, The parallel task scheduling engine performs scheduling according to a five-level hierarchical DAG topology execution logic, which includes initial serial testing, multiple parallel tests, conditional branch judgment, deep protection testing, and archiving. It also distinguishes between critical nodes and ordinary nodes to perform intelligent fault tolerance, including automatic retry for sampling out of tolerance, retesting for minor anomalies, circuit breaking and archiving for serious anomalies, and automatically skipping time-consuming high-voltage protection tests when basic tests fail.

7. The BMS multi-threaded parallel FCT test software system according to claim 1, characterized in that, The system supports the import and export of test plans and is suitable for FCT mass production testing of various products such as power battery BMS, energy storage BMS and portable lithium battery protection boards. It automatically summarizes test item data to generate test reports, supports statistical analysis of defective data, and reserves a data interface for MES system integration, realizing digital traceability management of mass production test data.

8. A BMS multi-threaded parallel FCT testing method, characterized in that, Includes the following steps: Construct a directed acyclic graph task topology for BMS test tasks, and classify the BMS test tasks into strongly time-series tasks with temporal dependencies and mutually independent parallel tasks. Traverse the directed acyclic graph task topology, execute the strongly sequential tasks serially, and allocate the mutually independent parallel tasks to a dynamic thread pool for multi-threaded parallel execution. Before parallel tasks access the BMS communication bus or test instrument, resource locks are requested through the communication hardware resource management module to queue up tasks that access the same communication bus or the same test instrument, and to allow tasks that access different hardware resources to be executed in parallel. The BMS sampling data, communication messages, and test results obtained from each task execution are pushed to a thread-safe message queue for unified collection and orderly storage.

9. The BMS multi-threaded parallel FCT testing method according to claim 8, characterized in that, When high-risk anomalies such as overvoltage, overcurrent, or communication failure are detected, the battery simulator and fault injection unit are reset and the excitation signal is cut off to perform hardware interlock protection for the test task in a high-risk abnormal state.

10. The BMS multi-threaded parallel FCT testing method according to claim 8, characterized in that, The system executes according to a five-level hierarchical DAG topology logic, which includes initial serial testing, multiple parallel tests, conditional branch judgment, deep protection testing, and archiving. It also distinguishes between critical nodes and ordinary nodes to perform intelligent fault tolerance. Specifically, it automatically retryes when sampling exceeds the tolerance, retests minor anomalies, triggers circuit breakers and jumps to archiving when serious anomalies occur, and automatically skips time-consuming high-voltage protection tests when basic tests fail. Furthermore, it generates JSON templates by dragging and dropping to configure test processes and task dependencies through a visual interface, enabling adaptation to different BMS models without modifying the underlying code.

11. 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 BMS multi-threaded parallel FCT test method as described in any one of claims 8 to 10.

Images