A battery detection method based on the merging of multiple central processing units

Abstract

This invention discloses a battery testing method based on the merging of multiple central processing units, specifically relating to the field of battery testing technology. The method includes the following steps: multiple central processing units are grouped into a device group, and under unified control, processes are distributed, executed in parallel, and their status is collected and verified for consistency, ensuring synchronous testing across all channels; when deviations or anomalies are detected, dynamic repair is performed through automatic reconnection, status repair, and process reconstruction mechanisms, ultimately completing data aggregation and storage, achieving efficient and stable multi-channel battery testing process control and anomaly handling; this invention achieves centralized scheduling of channel resources by configuring multiple central processing units into a unified device group; introduces status consistency verification and synchronization waiting mechanisms to improve the accuracy and stability of process execution; and ensures the integrity and traceability of testing data through structured data aggregation and cross-validation, enhancing the system's intelligence and scalability.

Description

Technical Field

[0001] This invention relates to the field of battery testing technology, and more specifically, to a battery testing method based on the merging of multiple central processing units. Background Technology

[0002] In the field of battery manufacturing and quality inspection, with the continuous expansion of battery production scale, battery testing systems have placed higher demands on the number of channels, parallel execution capabilities, and data processing performance. Traditional battery testing equipment typically uses a single central processing unit for control and data management. When faced with the process flow distribution and status feedback processing of a large number of channels, it often suffers from problems such as low execution efficiency, high response latency, and unbalanced load, making it difficult to meet the high-concurrency and high-stability testing requirements of modern production lines.

[0003] Some solutions have introduced detection architectures composed of multiple central processing units (CPUs) in an attempt to improve overall performance through distributed deployment. However, in practical engineering applications, existing parallel architectures with multiple CPUs still face numerous technical limitations in process control, anomaly management, and state synchronization. On the one hand, the channel mapping of each CPU typically uses a static configuration method, lacking the ability to reconfigure in real time to adapt to the detection task. This results in the inability to migrate affected channels to available nodes in a timely manner after a node fails, threatening the overall process stability. On the other hand, during the process execution phase, due to unavoidable fluctuations in communication between CPUs, misalignment of work step states and inconsistent process rhythms are prone to occur between different nodes. Existing consistency judgment mechanisms mainly rely on the comparison of work step numbers and communication handshake status, making it difficult to achieve fine-grained monitoring and error perception at the data level.

[0004] During the testing process, even with an automatic reconnection mechanism, issues such as command retransmission and inaccurate state rollback still exist once communication is restored after an interruption. In particular, there is a lack of process progress repair and compensation strategies centered on work step commands. More seriously, current systems mostly rely on single-point threshold judgments for identifying channel-level anomalies, failing to effectively identify "latent anomalies" caused by sampling offsets, equipment drift, or voltage fluctuations. This results in error accumulation in some channels before triggering explicit faults, affecting the accuracy of subsequent battery screening and judgment. Therefore, this invention proposes a battery testing method based on the merging of multiple central processing units to address the aforementioned problems. Summary of the Invention

[0005] To achieve the above objectives, the present invention provides the following technical solution:

[0006] A battery detection method based on the merging of multiple central processing units includes the following steps:

[0007] Equipment group configuration: In the host computer system, based on the requirements of the battery detection process for the number of channels and parameters, multiple central processing units are configured as a device group, and the mapping relationship between each central processing unit and the channel is established, so that multiple central processing units are logically managed and controlled as a single device unit.

[0008] Connection status detection and initialization: The host computer establishes a communication connection with each central processing unit through the transmission control protocol and periodically detects its connection status; when any central processing unit loses connection, the system automatically makes multiple reconnection attempts. After successful reconnection, the system performs time synchronization, channel mapping confirmation and step identification calibration on the central processing unit to ensure that its initial state is consistent with the equipment group.

[0009] Process distribution and parallel execution: The host computer distributes the preset battery testing process in the form of work step instructions to each central processing unit in the equipment group in parallel through a multi-threaded mechanism, and allocates instructions according to the channel mapping relationship to ensure that all central processing units execute the corresponding process under the same logical timing.

[0010] Status acquisition and consistency verification: During process execution, the host computer collects the execution status, step information and detection data of each central processing unit in real time, and compares the execution progress of each central processing unit in the equipment group according to the set consistency judgment rules. When it is found that the execution status of a certain central processing unit is different from that of other central processing units, the system puts the central processing unit into a synchronization waiting state and suspends its process execution to prevent process misalignment or data abnormality.

[0011] Anomaly Repair and Process Restructuring: For central processing units in the synchronization waiting state, the host computer continuously monitors their status changes; when the central processing unit completes communication recovery or anomaly elimination, the host computer reissues its incomplete work step instructions and protection parameters according to its most recent consistency verification record, and calibrates its execution progress and current configuration status; after the repair is completed, the central processing unit automatically exits the synchronization waiting state and rejoins the process execution of the equipment group;

[0012] Process completion judgment and data summary: When all central processing units have completed the corresponding detection process and passed the final cross-validation, the host computer records the process completion status, summarizes the detection data of all channels, and stores them in a structured manner according to the channel number and timestamp for battery performance analysis and subsequent sorting processing.

[0013] In a preferred embodiment, the mapping relationship between each central processing unit and the channel is bound by an index dictionary, and a static mapping table and a dynamic mapping cache are established initially. The mapping table records the central processing unit number corresponding to each channel number, the physical index of the channel in the central processing unit, the channel alias, and the serial number information in the device group. The mapping relationship can be added, deleted, adjusted, and named by the user through a visual configuration interface, and is used for precise instruction delivery during the process of sending the process.

[0014] In a preferred embodiment, the connection state detection employs a time-window-based multiple-polling mechanism, specifically including:

[0015] A threshold for the number of detections within a fixed time interval is set. If no response is received, the central processing unit is marked as offline. Once marked as offline, the communication recovery logic process is initiated, including releasing the old connection, rebuilding the transmission control protocol session, sending a handshake command, and comparing the returned unique identifier of the central processing unit. If the connection is successful, the initialization steps are performed; otherwise, a fault log is recorded and an alarm is triggered.

[0016] In a preferred embodiment, the multithreading mechanism refers to:

[0017] The host computer binds a globally unique process identifier, a channel unique index number, and a timestamp to each process instruction, and uses a preset distributed thread pool model for load balancing during the distribution process.

[0018] To ensure process synchronization, each thread must implement mutex lock control to avoid conflicts caused by multiple instructions writing to the same central processing unit at the same time. At the same time, a command sending confirmation mechanism is introduced. After each instruction is issued, the corresponding thread resources are only released after receiving a response confirmation from the lower-level machine. This achieves precise control over the issuance of process instructions and prevents process divergence caused by disordered processing order of the central processing unit.

[0019] In a preferred embodiment, the consistency judgment rules include three types of indicators: execution status comparison, step identifier comparison, and process time alignment. Specific rules include, but are not limited to:

[0020] The step number of all central processing units in the same equipment group must not differ by more than one step. If any central processing unit lags behind by two or more steps, the status deviation shall be marked.

[0021] The time difference between the current steps of all central processing units must not exceed the set threshold time; if it does, a status lock process will be performed.

[0022] If the timestamp of the data returned by any channel is n seconds earlier than the group's time base, it is marked as abnormal data, and the channel is forcibly suspended.

[0023] In a preferred embodiment, during the repair process, if a central processing unit is marked as permanently offline due to continuous communication failures, an automatic process reconfiguration mechanism will be activated. This mechanism automatically reallocates the channel processes handled by the abnormal central processing unit to other available central processing units based on the number of remaining central processing units in the current device group, channel load status, and mapping table backup, and regenerates the instruction scheduling diagram and allocation matrix. During this process, the process control table, channel mapping information, and system logs in the database are updated synchronously.

[0024] In a preferred embodiment, during the judgment process, the status information of all central processing units is cross-validated three times. The first verification is the comparison of the execution status of the work step, the second verification is the comparison of the channel completion flag, and the third verification is the curve data integrity check.

[0025] Under the condition that all verifications pass, the entire process is marked as complete. Curve data verification includes the number of sampling points, the range of maximum and minimum values, the sampling time span, and the sampling interval of each channel. If any channel's curve is found to have a breakpoint, abrupt change, or no data, the process will not be settled, it will be marked as a process failure, and detailed abnormal data points will be recorded for analysis and tracing.

[0026] In a preferred embodiment, during the data aggregation process after the process is completed, the detection data of each channel is structured and archived with time series as the main index, and an interface is provided to connect with the MES or WCS system to realize distributed data reporting. Each channel record includes, but is not limited to, multi-dimensional parameters such as voltage, current, temperature, pressure, internal resistance, channel number, process number, and acquisition timestamp. It supports exporting to standard format data files and can be used for curve analysis and filtering through visualization software.

[0027] In a preferred embodiment, during the consistency verification process, an outlier detection function is introduced to identify deviations in the channel data. The specific steps are as follows:

[0028] Step 1: Extract the continuous sampled value sequence within the current work step cycle from the voltage data of all channels under the same equipment group to construct the channel data set;

[0029] Step 2: Calculate the median, median absolute deviation, and local average rate of change for the data sequence of each channel, perform weighted summation after normalization, and generate the channel stability factor;

[0030] Step 3: Taking the equipment group as a whole, construct the residual matrix between each channel and other channels based on the channel stability factor, and apply the three-times median absolute deviation rule to mark outlier channels;

[0031] Step 4: For channels marked as outliers, issue a synchronization wait command to suspend the channel process until the next consistency check verifies that it has returned to normal.

[0032] In a preferred embodiment, a channel rescheduling strategy is introduced during the anomaly repair process, specifically including:

[0033] Construct a node graph of the central processing unit of the equipment group, with the central processing unit as the node and the channel transmission weight as the edge, and record the current channel load, historical error rate and latency of each central processing unit;

[0034] The dynamic weights of each edge in the graph are constructed using a channel load balancing factor and a historical error factor. The channel load balancing factor is obtained by calculating the ratio of the number of channels currently handled by the central processing unit to its maximum capacity limit. The historical error factor is obtained by statistically analyzing the frequency of abnormal events of the central processing unit within a specified historical period and mapping it to the ratio of the total number of tasks, thus obtaining a standardized score value representing the operational stability of the central processing unit.

[0035] For central processing units marked as abnormal, remove the node from the graph and start the shortest path calculation algorithm to find a new central processing unit whose channel can be mapped.

[0036] Under the new mapping relationship, the scheduling matrix is ​​regenerated and the process parameter migration is performed, including step parameters, curve sampling rules and synchronization timestamps;

[0037] After rebuilding the communication channels and mapping indexes, the process is reissued and the test process begins. If all channels pass the state consistency verification, the process execution of the entire device group is resumed.

[0038] The technical effects and advantages of this invention are as follows:

[0039] This invention achieves unified scheduling and centralized management at the logical level by configuring multiple central processing units (CPUs) in a host computer to form a unified device group and establishing a clear mapping relationship between CPUs and channels. In battery testing processes, different channels may correspond to different testing requirements and operating parameters. Traditional single-processor modes are prone to problems such as task backlog, response delays, or resource allocation conflicts when facing a large number of channels running simultaneously. This invention logically integrates multiple CPUs, forming a virtual, unified device unit. The number of CPUs and channel binding relationships can be expanded as needed based on the number of testing tasks and parameter complexity. For example, in a system with a testing capacity of 480 channels, six CPUs can be configured, each managing 80 channels, and tasks can be parallelized through centralized host computer scheduling. This approach effectively improves the system's horizontal scalability, enhances overall processing capacity, and avoids the risk of system lag or task delays caused by single-node performance bottlenecks. Furthermore, through logical mapping, the system can dynamically adjust the channel binding structure to adapt to changes in different battery batches or process parameters, enhancing the system's flexibility and maintainability in actual testing scenarios.

[0040] This invention ensures synchronization and data consistency among multiple central processing units (CPUs) executing the same process flow by introducing a real-time acquisition and consistency verification mechanism for execution status throughout the entire process. This is particularly important when the battery testing process involves multiple critical steps, such as charging / discharging, internal resistance testing, and temperature recording. The start and end times of each step must strictly correspond; otherwise, the final performance data will be offset or distorted. This invention employs a multi-threaded parallel mechanism during the process issuance phase, issuing step instructions to each CPU and matching them using a global timestamp, channel mapping index, and unique process number. During execution, the host computer continuously collects the step status, feedback data, and time progress of each CPU, comparing them according to predefined rules. When a CPU is found to have significant lag or abnormal behavior, its process is immediately paused and placed in a synchronization waiting state. This mechanism effectively avoids the problem of the entire equipment group's process being misaligned due to anomalies in individual nodes, and subsequent repair mechanisms can be used to recalibrate the abnormal CPU and restore the process. This verification mechanism enhances the system's robustness and real-time correction capabilities, making it particularly suitable for complex industrial environments where network fluctuations, communication packet loss, or equipment jitter occur frequently, ensuring stable process execution and reliable test data.

[0041] After the process execution is complete, this invention performs final cross-validation on the process status of all central processing units and uniformly summarizes the detection data from all channels, constructing a structured time-series data archiving system, which greatly improves data integrity and subsequent processing efficiency. Specifically, after each central processing unit completes its corresponding detection task, the host computer performs three cross-validations from multiple perspectives based on preset completion judgment rules: including whether the step status meets expectations, whether the channel provides a completion signal, and whether the curve data is continuous and complete, ensuring that the detection process is truly functionally closed-loop. After all validations pass, the system uniformly and structurally archives the raw detection data from all channels, organizing it according to the channel number and timestamp as the primary key, ensuring high consistency, high efficiency, and high readability of the data during querying, backtracking, and tracing. For example, the detection data includes multi-dimensional data such as voltage, current, and temperature sampled once per second. After being structured, it can be directly imported into the battery performance analysis system to achieve rapid screening, batch analysis, and intelligent early warning. The present invention also provides an interface for the data archiving system, which can be connected to the manufacturing execution system and the warehouse control system to realize the automatic reporting of test data and production linkage, which facilitates the formation of a quality tracking closed loop in a larger production system, thereby improving the digitalization and intelligence level of the entire battery manufacturing process. Attached Figure Description

[0042] To facilitate understanding by those skilled in the art, the present invention will be further described below with reference to the accompanying drawings;

[0043] Figure 1 This is a schematic diagram of a battery detection method based on the merging of multiple central processing units in this invention. Detailed Implementation

[0044] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of the present invention.

[0045] Reference Figure 1 The following examples were obtained:

[0046] Example 1: A battery detection method based on the merging of multiple central processing units, comprising the following steps:

[0047] Equipment group configuration: In the host computer system, based on the requirements of the battery testing process for the number of channels and parameters, multiple central processing units are configured as a device group, and the mapping relationship between each central processing unit and the channel is established, so that multiple central processing units are logically managed and controlled as a single device unit. This step is used to establish a unified entry point for the system in terms of logical structure, solve the structural limitation of one central processing unit corresponding to one storage location in the traditional testing system, and enable multiple central processing units to achieve parallel operation through unified configuration, thereby meeting the production requirements of a high number of channels and laying the foundation for unified scheduling of subsequent processes.

[0048] Connection Status Detection and Initialization: The host computer establishes communication connections with each central processing unit (CPU) through the transmission control protocol and periodically checks its connection status. When any CPU disconnects, the system automatically attempts to reconnect multiple times. Upon successful reconnection, the system performs time synchronization, channel mapping confirmation, and step identifier calibration on the CPU to ensure that its initial state is consistent with the device group. This step is significant because it ensures that the communication status of all CPUs in the device group remains valid. Especially after network fluctuations or brief recovery from unit failures, a unified initialization mechanism ensures that the CPU maintains a consistent baseline state with other CPUs before the process is executed. This ensures that the starting point of the entire process is coordinated and consistent, avoiding data misalignment or step disorder caused by initialization errors.

[0049] Process Distribution and Parallel Execution: The host computer distributes the preset battery testing process as step instructions to each central processing unit (CPU) in the equipment group in parallel through a multi-threaded mechanism. Instructions are allocated according to channel mapping relationships to ensure that all CPUs execute their corresponding processes under the same logical timing. This step achieves synchronous distribution and parallel execution of the testing process across multiple CPUs. The multi-threaded control mechanism improves system scheduling efficiency while ensuring consistent operation of each channel under the same step logic. Precise application of channel mapping relationships ensures on-demand distribution of process instructions, avoiding channel mismatches or execution errors, and providing technical support for large-scale concurrent testing.

[0050] Status Acquisition and Consistency Verification: During process execution, the host computer collects the execution status, step information, and detection data of each central processing unit (CPU) in real time. Based on predefined consistency judgment rules, it compares the execution progress of each CPU in the equipment group. When a discrepancy is detected between the execution status of a CPU and other CPUs, the system places that CPU into a synchronization waiting state, suspending its process execution to prevent process misalignment or data anomalies. This step is the core of the entire method's control. Through real-time status acquisition and logical consistency comparison mechanisms, the system can dynamically detect execution deviations between CPUs and intervene in advance to prevent any CPU delay or data anomaly from interfering with the overall process. The synchronization waiting mechanism ensures overall process consistency and improves the system's ability to respond to dynamic anomalies and data integrity.

[0051] Anomaly Repair and Process Restructuring: For central processing units (CPUs) in a synchronization waiting state, the host computer continuously monitors their status changes. Once the CPU completes communication recovery or anomaly elimination, the host computer, based on its most recent consistency check record, reissues the incomplete step instructions and protection parameters, and calibrates its execution progress and current configuration status. After repair, the CPU automatically exits the synchronization waiting state and rejoins the equipment group's process execution. This step endows the system with anomaly self-healing capabilities. When a CPU is isolated due to a brief anomaly, its execution context can be automatically restructured after the status is restored, achieving process recovery and seamless integration. This process restructuring strategy effectively avoids the risk of interrupting the entire process due to a single point of failure, improving the continuity of equipment group operation and overall fault tolerance.

[0052] Process Completion Judgment and Data Aggregation: Once all central processing units have completed their corresponding testing processes and passed final cross-validation, the host computer records the process completion status, aggregates the testing data from all channels, and stores it in a structured format according to channel number and timestamp for battery performance analysis and subsequent sorting. This step serves as the endpoint of the process loop, ensuring logical consistency and data integrity in the execution results of each central processing unit. Cross-validation is used to determine whether the process is truly complete, preventing premature termination due to misjudgments by individual central processing units. The structured data directly supports battery performance traceability, sorting algorithm input, and process optimization, representing a significant aspect of the data value realization of this method.

[0053] Based on the requirements of battery testing processes regarding the number of channels and parameters, a logical assembly of multiple central processing units (CPUs) is constructed, and an initial equipment group structure is established. In the configuration module of the host computer, engineers first estimate the total required channel capacity based on the technical requirements of the target battery testing process, including key parameters such as the number of channels corresponding to each battery group (e.g., at least eight channels per battery pack), the detection current range, and voltage measurement resolution. For example, if a certain production station needs to support the parallel testing of sixteen batteries, and each battery requires eight channels for acquiring signals such as voltage, current, internal resistance, and temperature, then a total of one hundred and twenty-eight independent channels are required. After matching the capabilities of existing CPU equipment (e.g., a single CPU can support a maximum of thirty-two channels), it is determined that this equipment group needs to integrate four CPUs. Subsequently, a new logical equipment group is created in the configuration interface. The task process corresponding identifier (e.g., "high-rate fast full-capacity selection segment") is entered in the equipment group naming and description fields, and four CPU entities are added as member nodes, providing a structural foundation for establishing the mapping relationship between each CPU and the channels.

[0054] The mapping relationship between each central processing unit (CPU) and channel is bound through an index dictionary, and a static mapping table and a dynamic mapping cache structure are established. The construction of this mapping relationship is crucial for ensuring the accuracy of process scheduling. In this step, a two-way binding structure is established for each channel in the device group. First, a mapping dictionary between channel numbers and CPU numbers is generated, with the channel number as the primary key and corresponding to a value structure containing four items: the CPU number where the channel resides, the physical index of the channel within that CPU (e.g., channel 5), the logical alias of the channel (e.g., "left side group 3 temperature control channels"), and its sequence number within the entire device group (e.g., "device group channel 21"). For example, channel with logical number 21 might correspond to CPU number 3, its physical position within that CPU is 5, and it would be named "medium temperature zone A5 point sampling". This mapping relationship, after its initial configuration, will be written to the static mapping table and stored in a configuration file in XML or JSON format. Simultaneously, to improve runtime lookup performance, this static table is loaded into memory using a hash function to generate a dynamic mapping cache, achieving millisecond-level reverse lookup capabilities. All subsequent process instruction scheduling, data acquisition mapping, and status synchronization operations are completed based on this mapping cache structure.

[0055] The mapping relationships are added, deleted, adjusted, and named by the user through a visual configuration interface, and logical verification and conflict detection are implemented. Considering the needs of process adjustments, channel replacements, or hardware structure changes, the mapping relationships must have flexible adjustment capabilities. In this step, the user can independently edit the four attributes of any channel through the visual configuration interface provided in the host computer. Each modification operation automatically triggers the verification mechanism. For example, when the user attempts to configure two channels as the same physical central processing unit index, the system immediately prompts "channel conflict"; when the user mistakenly leaves the logical alias empty, the system triggers a "naming non-standard" warning; for cases where the serial numbers in the device group are not consecutive or out of range, an error message will also pop up. In addition, the interface provides functions such as "batch import channel mapping", "copy existing central processing unit configuration", and "automatically fill aliases according to naming rules" to improve the efficiency of large-scale configuration. After all modifications are confirmed and submitted by the user, the dynamic mapping cache is updated immediately, while the static mapping table retains historical versions for configuration backtracking. This configuration method greatly improves the flexibility of device deployment and switching, and avoids the high error risk caused by manual table configuration.

[0056] During the process of sending instructions, the mapping relationship is used for precise instruction delivery, ensuring accurate channel matching for multi-threaded process distribution. During the actual battery testing process startup, the process engine matches the target channel for each step instruction based on the channel mapping relationship configured above. For example, if a step requires constant current charging of device group channel number 35, the system will use dynamic mapping cache to find that the channel is located at central processing unit number 2 and physical channel index 3, and encapsulate the step instruction into a binary command packet targeting central processing unit number 2 and channel 3, sending it to the corresponding processing unit for execution. In parallel sending, the thread pool scheduler splits the task queue according to the channel number range to ensure that multiple threads do not conflict with each other's instructions. Each instruction is marked with identification information such as the source channel number, logical device group number, and timestamp, facilitating subsequent status feedback matching and anomaly identification. Furthermore, if a hot switch is required during process sending due to channel status anomalies, the system will also call the mapping table to query backup channels, achieving dynamic replacement scheduling. This process ensures that in the collaborative work of multiple central processing units, any process instruction can be precisely mapped to a unique, correct, and clearly defined channel without human intervention, thereby improving the overall level of automation and reliability.

[0057] Based on the Transmission Control Protocol (TCP) communication establishment mechanism, combined with a time window multiple-polling strategy and a logical identification and confirmation mechanism, the connection status awareness and initialization recovery of multiple central processing units (CPUs) can be realized. Specifically, the steps include: establishing an initial connection via TCP and recording a unique identifier as a handshake confirmation credential: After the device group is configured, the host computer initiates connection requests based on TCP sequentially according to the communication addresses of each CPU in the device group. Each connection attempt includes a three-way handshake confirmation process, along with the current host computer timestamp information for subsequent time synchronization. When the connection is successfully established, the lower-level unit returns a unique identifier, which includes the current device number, hardware version number, current channel quantity, and an encrypted identity fingerprint, used to identify whether it is a legitimate target CPU. For example, the CPU numbered 3 might return the identifier as: "Device number 3, version 1.2.7, channel quantity 32, identity signature A3B9F2C4". The host computer compares this returned data with the records in the device group configuration to confirm that the connection object is consistent with the current mapping binding, avoiding logical confusion caused by communication port changes or mismatches. If the identification is successful, the central processing unit is recorded as "successful initial access" and a keep-alive mechanism is established to enter the next periodic detection phase.

[0058] To accurately determine connection status fluctuations, a time-window-based multiple-polling detection mechanism is implemented: To ensure continuous and stable communication capabilities among multiple central processing units (CPUs) before the battery detection process begins, this invention introduces a connection status polling mechanism based on time windows. Specifically, after a connection is established, each CPU is included in a polling list within a fixed period. For example, the detection period is set to poll every 5 seconds, and each detection window contains 10 consecutive polling records. In any round, the host computer sends a "status heartbeat" command to the CPU, requesting it to return summary information such as online status, temperature, and voltage, and records the response time. If no response is received in 3 consecutive polls, it is considered a "short-term anomaly"; if the number of responses is less than 4 within the 10 detection windows (i.e., the response rate is less than 40%), the CPU is officially marked as "offline." For example, if CPU number 2 successfully responds only 3 times within 50 seconds, the host computer immediately terminates the process initialization action for that channel and proceeds to the next communication recovery logic process, ensuring the communication consistency of the entire device group before the process starts.

[0059] The communication recovery logic process includes connection release, session reconstruction, and identity verification: Once a central processing unit is marked as offline, this invention attempts to repair the connection path and re-authenticate through a refined communication recovery mechanism. First, it releases any residual session resources from the previous Transmission Control Protocol (TCP) connection, including releasing the connection handle, closing port resource occupancy, and clearing the receive buffer. Then, it re-initiates a connection request, executes the complete handshake confirmation process, and sends an identity verification command to the central processing unit again, requesting it to return key fields such as device number, current time, and firmware version. If the returned content is inconsistent with the record from the initial connection (e.g., device number changed, channel quantity mismatch, or identity signature mismatch), an abnormal event is immediately recorded, and the process initialization is prohibited. If the returned content matches the original record, communication recovery is considered successful, and the initialization phase begins. During this process, each failed attempt is written to the "Connection Anomaly Log," recording the time, reason for failure, connection port, and operation number for subsequent maintenance and fault tracing. For example, if the central processing unit 3 fails to connect three times in a row, the log will show: "Time 15:26, Device 3, three communication failures, connection port 5048, status code timeout".

[0060] For successfully reconnected central processing units (CPUs), time synchronization, channel mapping confirmation, and step identifier calibration are performed: When a CPU is determined to have "connection restored effectively" after communication is restored, the host computer immediately sends it the current standard timestamp to achieve time synchronization, ensuring that all processing units calculate sampling points and step cycles using a consistent time base during process execution. Next, the CPU resends its channel mapping relationship, including channel number, physical ranking, logical alias, and device group number, to confirm whether the channel structure within the unit has changed. If a change in the number of channels or a numbering conflict is found, its process mounting is terminated. After mapping confirmation, step identifier calibration is performed, specifically including issuing the progress identifier of the current device group process (such as "current step number 5", "cycle number 2", "cumulative sampling points 1800", etc.), which is then aligned by the CPU. After all information is confirmed to be correct, the unit is recorded as "ready to be put into process status," and its status label in the device group is updated to "initialized." This mechanism ensures that communication recovery is not only about restoring the physical link, but also includes the reconstruction of the logical state, enabling the device group to re-integrate the unit at a unified pace, thus ensuring the integrity of process execution and data continuity.

[0061] After completing the device group configuration and connection status detection and initialization, multiple central processing units (CPUs) are in a ready-to-run state with established communication, consistent status, and confirmed mapping relationships. At this point, the process distribution and parallel execution, as the core scheduling step of the entire battery testing task, are triggered. The purpose of this step is to accurately and synchronously distribute the preset testing process to the corresponding channels in each CPU, and to ensure that all CPUs execute the corresponding process processes in parallel under the same logical timing through an efficient and thread-safe method. Specifically, this includes the following steps: binding a globally unique process identifier, a unique channel index, and timestamp information to each process instruction to ensure the traceability of the instruction throughout the delivery chain; before the battery testing process officially starts, the host computer first parses the set process flow and breaks down the overall process into several process instructions according to the step granularity. Each process instruction contains information such as the corresponding target channel number, the current step type (e.g., constant current charging, constant voltage holding, static sampling, etc.), duration, voltage and current settings, polarity settings, and protection parameters. To achieve precise scheduling, the host computer binds three key identifiers to each instruction upon generation: first, a globally unique process identifier, used to mark the overall detection process to which the instruction belongs (e.g., 202511101248-process number A1); second, a unique channel index number, used to locate the physical channel of the instruction's target within the entire equipment group (e.g., channel number 97, corresponding to central processing unit number 3, channel number 1); and third, a timestamp, recording the host computer's local time (accurate to milliseconds) when the instruction was generated, used for instruction sorting and feedback verification. All binding information is embedded in the instruction header in the form of a data structure and serves as a verification benchmark field in subsequent sending, confirmation, and recording processes.

[0062] The process instructions are issued through a pre-defined distributed thread pool model, and the instructions are accurately allocated to the target central processing unit (CPU) according to the channel mapping relationship. To improve process scheduling efficiency and avoid delays or bottlenecks caused by serial command delivery, this invention introduces a distributed thread pool model in the host computer. Before the process is issued, the number of threads and resource limits of the thread pool are dynamically allocated according to the number of CPUs and channels in the device group. For example, when the device group contains four CPUs and a total of 128 channels, the thread pool can be set to 16 threads, with each thread responsible for scheduling eight to ten channels. When each thread starts, it automatically looks up the "channel mapping relationship", uses the unique index number of the channel as the key, finds the corresponding CPU number and physical channel number in the memory-mapped cache, and encodes and packages the instruction into a recognizable command frame and sends it to the corresponding CPU. For example, the process instruction of channel number 47 will be assigned to thread number 3, which will schedule it to CPU number 1 and physical channel number 15. The entire thread pool has an adaptive load balancing mechanism that dynamically adjusts the scheduling pace based on the central processing unit's response rate and thread execution rate to ensure that each central processing unit receives a balanced task load during the process of process distribution.

[0063] To prevent command overwriting or process disruption caused by multiple threads writing instructions to the same central processing unit (CPU) simultaneously during parallel instruction transmission, a mutex lock control mechanism is implemented for all threads. Since a single CPU may manage multiple channels, multiple threads may concurrently write to the same CPU command buffer while sending process instructions to their respective channels. To prevent conflicts, this invention incorporates a mutex lock control mechanism at the thread scheduling layer. Each CPU corresponds to an independent instruction write lock. Before a thread can write an instruction to a CPU, it must first acquire the lock, and release the lock resource after writing and receiving feedback. For example, when thread 5 prepares to write a constant current instruction to CPU 2 (channel 26), the system will first acquire the mutex lock for CPU 2. If the lock is currently held by thread 2, thread 5 will enter a waiting queue until thread 2 releases the lock. This mechanism ensures that each CPU receives at most one process write instruction at any given time, avoiding serious consequences such as out-of-order commands, process stage disruption, or premature execution of steps due to thread contention. The lock acquisition and release states are managed in the command scheduler using a state dictionary, which records the thread ID, central processing unit number, and lock holding time for scheduling monitoring and performance optimization analysis.

[0064] A command sending confirmation mechanism is introduced to ensure that thread resources are released only after each command is sent and a response confirmation is received from the central processing unit, forming a closed loop for command sending. To achieve a reliable closed loop for the transmission and execution of process commands on the communication link, this invention requires the target central processing unit to return a command reception confirmation after each command is sent. The confirmation content includes the received process unique identifier, channel index, command length check value, and the current central processing unit timestamp. The host computer will start a confirmation listener during thread execution and wait for feedback information within a specified time. If the confirmation content is consistent and the return status is "command successfully received", the thread resources are released and the command is marked as successfully sent; if no response is received within the timeout or the confirmation data verification fails, the thread will re-enter the command retransmission queue and the communication anomaly count of the central processing unit will be recorded. Taking a practical application as an example, when thread number 9 sends a constant voltage command for channel 68 to central processing unit number 3, if the feedback "command ID202511101248-16 successfully received" is received within 300 milliseconds, the thread task is marked as completed; if no response is received or the content is inconsistent, the retry mechanism is entered. This verification mechanism ensures that each process instruction has a verifiable and complete execution chain, significantly improving the stability and security of parallel processes with multiple central processing units.

[0065] The pre-defined distributed thread pool model has been widely applied in multi-task concurrent processing scenarios, particularly in high-performance control platforms, industrial automation management platforms, and real-time data distribution systems, where it has a mature application foundation. Its core principle lies in pre-setting a certain number of thread resources and centrally managing them in a scheduling pool. When a task arrives, there's no need to dynamically create threads; instead, existing idle threads are allocated from the pool for processing. After processing, the thread resources are returned to the pool for reuse, significantly reducing performance loss and resource contention caused by frequent thread creation and destruction. In multi-task concurrent scenarios, this model, through queuing strategies, thread priority control, and resource allocation weight settings, can achieve reasonable task distribution and load balancing among multiple processing units, improving overall operating efficiency and response time. Combined with the "process issuance and parallel execution" technical solution in this invention, the pre-defined distributed thread pool model is mainly applied to the concurrent scheduling of battery testing process steps. In scenarios where the battery testing equipment group consists of multiple central processing units, each corresponding to multiple channels, a single process issuance often involves a large number of parallel process steps. By pre-setting multiple thread resources in a thread pool and dynamically allocating a thread for processing each instruction, efficient control logic can be achieved to simultaneously issue multiple process instructions to different central processing units. This thread pool dynamically calculates the scheduling target based on the current channel mapping relationship and, while ensuring thread mutex control, guarantees that instructions will not be interleaved and written to the same processing unit. This solves the common contention problem in multi-threaded scheduling and achieves the goal of this invention: "ensuring that all central processing units execute the corresponding process flow under the same logical timing."

[0066] After multiple central processing units (CPUs) receive and synchronously execute process instructions, status acquisition and consistency verification are activated as key data monitoring and logical consistency control steps. This step aims to continuously track the real-time operating status of each processing unit during the battery testing process, collect its corresponding step information and testing data, and perform a horizontal comparison of the process execution progress of all processing units based on preset consistency judgment rules. When a deviation risk or abnormal tendency is detected, a "synchronization waiting state" is immediately triggered, forcibly suspending the process execution of individual processing units to ensure that the overall process is not misaligned due to a single node anomaly, thereby affecting the detection accuracy of the entire equipment group. Specifically, this includes the following: the host computer collects the operating status, current step information, and channel detection data of each CPU in real time during process execution and constructs an equipment group status mapping table; to obtain real-time status data under the current process, the host computer sends status request signals to each CPU at a set frequency. The returned signal includes three main categories: first, the current running status identifier, such as "in execution," "waiting for next step," or "abnormal exit"; second, the current step identifier, including step number, start time, execution duration, and remaining step time; and third, a summary of the detection data for each channel, including real-time voltage, current, temperature, internal resistance, and channel timestamp. For example, processing unit number three returns that it is currently in the seventh step, "constant current charging stage," having executed for 920 milliseconds with 800 milliseconds remaining. The current channel's measured voltage is 3.76 volts, current is 1.45 amps, and the timestamp is the tenth sampling period since the start of execution. The host computer summarizes the data returned by all processing units into a status mapping table. Each row in the table represents the current execution status of a processing unit, laying the foundation for the next execution comparison.

[0067] Based on consistency judgment rules, the execution status of each processing unit in the equipment group is compared horizontally to identify deviation nodes. The judgment rules preset in this invention mainly include three types of indicators: execution status comparison, step identifier comparison, and process time alignment. First, the "running status identifiers" returned by all processing units are compared to ensure that they are all in the "execution" stage. If it is found that individual processing units have entered the "waiting for the next step" or "retrying" states, they are marked as status deviations. Second, the current step numbers of each processing unit are compared. If the difference in number is greater than one step, for example, a processing unit is in the fifth step while most processing units are in the seventh step, then the processing unit is marked as "progress lagging," and this is judged as a status deviation. Third, process time alignment analysis is performed, that is, the current step execution time of each processing unit is compared. For example, if the average execution time is 1,500 milliseconds, but a processing unit only executes for 600 milliseconds, then the node is marked as "execution time deviation." After the three indicators are combined for judgment, as long as any indicator is judged to be abnormal, the node is marked as a status deviation and proceeds to the next control process.

[0068] If a deviation is found between the execution status of a processing unit and other nodes in the equipment group, it is placed into a synchronization waiting state, suspending its current step execution and freezing the data flow of the relevant channels. After the state deviation is confirmed, the host computer sends a "synchronization waiting command" to the processing unit, forcing it to suspend the current process execution. After the command is executed, the processing unit freezes the current step execution, maintains stable voltage and current output of the channel, prohibits entering the next step, and marks its own status as "synchronization waiting". At the same time, the host computer suspends the corresponding detection data receiving process. For example, for the sixth channel, if its processing unit enters the waiting state, the host computer will no longer receive subsequent sampling values ​​of that channel to prevent discontinuous curves. In the synchronization waiting state, the processing unit can continue to respond to status request signals, but is not allowed to execute process changes. This effectively avoids the risk of process "misalignment", especially in multi-cell synchronous detection tasks. If some channels end their steps prematurely, leading to missorting or data offset, it will directly affect the accuracy of battery performance judgment.

[0069] To address timestamp anomalies in channel detection data, the system determines whether the data is abnormal based on the current time base of the equipment group. For example, a threshold of two seconds is used. Besides the ratio of step number to execution time, the timestamp of the channel's collected data is also a crucial reference factor in consistency verification. Assume that the timestamp returned by each channel in the equipment group must not be earlier than the minimum execution time within the current group, i.e., the group's time base n seconds, where n represents two seconds. In practice, if the execution times of all channels in the current equipment group are concentrated between 1200 and 1400 milliseconds, then if the timestamp returned by any channel shows that it only executed for 200 milliseconds, which is earlier than the average time base of 1200 milliseconds (two seconds), the data returned by that channel is considered "time base abnormal." In this case, the host computer will immediately suspend data reception for that channel and send a "data abnormality lock command" to its processing unit, requesting resynchronization of the time base and restarting of the current step execution. For example, if the 92nd channel fails to synchronize the time correctly after the processing unit recovers, causing the timestamp to fall back to the initial time point of the process, this abnormal logic will be triggered, effectively avoiding consequences such as battery curve distortion and data misjudgment caused by time base disorder.

[0070] During status acquisition and consistency verification, if a central processing unit (CPU) is found to have prolonged communication anomalies and fails to reconnect after multiple retries, and its cumulative communication failure count exceeds a set threshold, the CPU will be marked as permanently offline. To avoid causing overall process interruption of the device group, this invention provides an automatic process reconfiguration mechanism. This mechanism dynamically reconfigures process delivery paths and channel scheduling schemes based on the current device group structure and operating status, ensuring process continuity and data integrity. Specifically, it includes the following steps: Based on the number of remaining CPUs and channel load in the current device group, the target CPUs that can participate in process takeover are identified. After a CPU is confirmed to be permanently offline, the automatic process reconfiguration mechanism immediately retrieves the CPU status table and channel mapping information of the current device group, calculates the number of remaining available CPUs after removing the abnormal CPU, and their current channel load. Channel load is measured based on the number of channels currently carried by each central processing unit (CPU). For example, if the equipment group originally consisted of four CPUs, and CPU number two has failed, then CPUs numbered one, three, and four will be considered as takeover candidates. If CPU number three currently carries thirty-two channels, while CPU number one carries only twenty-four channels, then channels will be preferentially reallocated to CPU number one. In principle, load allocation should avoid concentrating all reconstruction tasks on a single CPU to ensure load balancing after reconstruction, thereby improving data consistency and the efficiency of subsequent process synchronization.

[0071] By backing up data using a mapping table, all channel process information managed by permanently offline central processing units is extracted, and a channel redistribution list is constructed. The device group establishes a complete static mapping table during the initial configuration phase and records the current central processing unit, physical channel location, step execution status, and alias number for each channel through dynamic mapping caching during operation. When the automatic process refactoring mechanism is triggered, the host computer calls this mapping table backup to extract all process parameters for the channels corresponding to the permanently offline central processing units, including the current step number, remaining step sequence, completed data segment index, and sampling rules, and organizes this information into a channel redistribution list. For example, if central processing unit number two manages 32 channels (numbers 13 to 44) and is currently in step eight, the redistribution list will record the current status and complete historical trajectory of these 32 channels, providing a reference for subsequent process continuation and data alignment.

[0072] Based on the redistribution list and the weights allocated to the remaining central processing units, a new instruction scheduling graph and allocation matrix are generated, and each channel process is remounted. The automatic process reconfiguration mechanism in this invention, after completing the analysis of available resources and the organization of the channel list, will reconstruct a scheduling graph adapted to the current device group structure through instruction scheduling logic. In this graph, each edge represents the scheduling mapping relationship between a certain channel process and a certain central processing unit, and the weight of the edge is determined by the channel load balancing factor and the historical error factor. A new allocation matrix is ​​generated based on this graph, specifying which physical channel location in which central processing unit each channel will be remounted to. Taking channel number nineteen as an example, if it is scheduled to central processing unit number one, its instruction scheduling record will mark the original process, current step position, timestamp information, and synchronization identifier of the channel, and the process remounting will be automatically executed. During the remounting process, it is ensured that the channel fully inherits the process context on the new central processing unit and achieves seamless data integration.

[0073] After allocation is completed, the process control table, channel mapping information, and system logs in the database are automatically updated to ensure data consistency and historical traceability. Once the new scheduling relationship officially takes effect, the host computer will synchronously update three types of core data tables: First, the process control table records the current execution status of each channel, its current process number, and the time of re-takeover; second, the channel mapping information table updates channels originally managed by the abnormal central processing unit with the new central processing unit number and physical index location, and remaps identifier fields such as aliases and channel unique index numbers; finally, the system log file records detailed information such as the trigger time of this process refactoring, the abnormal central processing unit number, the number of affected channels, the old and new mapping relationships, and changes in the scheduling diagram. This log is not only used by technicians to review historical process changes but also serves as additional metadata for "scheduling path changes" in battery testing results for subsequent data analysis and process optimization judgments.

[0074] After completing anomaly repair and process refactoring, all available central processing units in the equipment group have re-established stable channel scheduling relationships and continue to execute their assigned processes. To ensure the logical closed loop and accurate data integrity judgment of the entire battery testing process, this invention proposes a process completion judgment mechanism based on multi-level cross-validation, and performs structured data aggregation operations on this basis. This judgment mechanism uses the process execution status, channel execution results, and curve data validity of all central processing units as core evaluation criteria, divides them into three cross-validations, and achieves closed-loop recording through process completion marking and anomaly data tracing mechanisms. Specifically, it includes the following steps: performing the first verification of process completion, i.e., comparing the step execution status, to ensure that all central processing units have executed to the last step and are in the finished state. When the equipment group enters the end of the process, the host computer starts to retrieve the current step execution status of each central processing unit and performs a horizontal comparison operation. The specific method is: traversing each central processing unit node in the equipment group, reading the current step number and execution status code recorded in its process control register, and judging whether it has completed all preset steps. For example, in a certain testing batch, the equipment group has a total of twelve steps. If the central processing unit (CPU) numbered five shows that it has completed the twelfth step and the execution status code is "Completed," then the CPU is considered to have performed normally. If any CPU is still in the eleventh step or shows the status code "Waiting for data confirmation," then that node is determined to have not completed the process and does not meet the initial verification conditions. Only when all CPUs are in the final step and in the "Completed" state does the system consider the initial verification to have passed.

[0075] The second verification process involves comparing channel completion flags to confirm the actual completion of each channel's process and verify the integrity of the work step sequence. After all central processing units pass the initial status comparison verification, the host computer further judges the execution result of each channel. This judgment is based on reading and comparing the completion flag bit bound to each channel and the content of the process instruction stack. Each channel generates a process completion flag upon completion, including "channel number, final work step number, completion timestamp, and channel status identifier." For example, channel number 104 in a certain batch shows that it has completed the twelfth work step, with a timestamp of 2:20 PM and a status identifier of "completed and data complete." If a channel is missing its completion flag or has an abnormal completion time more than five minutes earlier than the minimum time reference within the group, the channel's process is considered abnormal and fails the second verification. Simultaneously, the host computer also compares the work step sequence execution log of each channel to confirm whether there are any issues such as missing work steps, duplicate execution, or premature jumps in the process instructions. Only when all channel completion flags match the preset process and are complete is the second verification passed.

[0076] The final round of verification, namely curve data integrity verification, ensures the quality, continuity, and reasonableness of the channel-acquired data. After passing the first two rounds of process status and process logic verification, to guarantee the analytical value of the data and the accuracy of subsequent sorting, the host computer will perform an integrity verification of all channel curve data. This verification includes four types of indicators: First, sampling point count verification. If the preset sampling frequency is ten times per second and the duration of a single step is three minutes, the number of sampling points should not be less than 1,800. If it is less than 1,600, it is considered a missed sample. Second, maximum and minimum value range verification, which checks whether the maximum and minimum values ​​of the curve data are within a reasonable range. For example, the voltage curve should be between 2.5 and 4.3 volts. If it exceeds this range, it is considered an abnormal data point. Third, sampling time span verification, which confirms whether the curve time axis coverage is complete. If there is a data time interval greater than three seconds, it is marked as a breakpoint data point. Fourth, sampling interval verification for each channel, which requires that the time difference of all continuous sampling should remain stable. If the interval between any two points exceeds one second, it is marked as a sudden change in data. For example, if channel number 118 has no data records for 50 seconds in the ninth step, it is identified as a breakpoint channel and cannot pass the final verification. The curve data is considered complete only when all four types of indicators are within the acceptable range.

[0077] Assuming all three cross-validations pass, the overall process is marked as complete, triggering a data aggregation mechanism to structure and store the channel detection data. Once all central processing units confirm completion, all channel process flags match, and all channel sampling curves are complete, the host computer marks the batch of detection tasks as "overall process complete." Subsequently, the data aggregation process is initiated to structurally archive the raw detection data from all channels. Each channel record is stored using the channel number and sampling timestamp as the primary key, and includes multi-dimensional parameters such as step number, voltage, current, temperature, internal resistance, sampling cycle number, equipment group number, and detection batch number. This data is stored in a designated database table, supporting subsequent indexing, retrieval, curve reconstruction, or sorting and classification by batch, channel, step, or parameter. Simultaneously, to improve data traceability, the host computer records all completion flags, status records, abnormal reconstruction events, and validation process logs, archiving them uniformly as metadata for the batch's operational process. If any channel fails the above verification, the entire process will not be settled, the system will mark it as a process failure, automatically lock the data status of that channel, and record the abnormal data points, channel number and failure reason as the basis for subsequent traceability analysis and process optimization.

[0078] After verifying the process execution status and final curve data, this invention further enters the data aggregation stage after the process is completed. The core objective of this stage is to uniformly extract, calibrate the timeline, and structurally archive the channel detection data distributed across multiple central processing unit memory areas, and provide standard interface capabilities with the manufacturing execution system and warehouse control system to ensure the efficient execution of subsequent tasks such as battery process analysis, intelligent sorting, data visualization, and batch quality traceability. Specifically, this includes the following steps: batch extraction of all channel detection data from the completed process, and time-series sorting based on channel number and acquisition timestamp; after the process is marked as completed, the upper-level data management module automatically initiates a data retrieval request, sequentially accessing the buffer and result register in each central processing unit to extract all sampling data for each channel throughout the entire process. Each sampling record includes, but is not limited to, fields such as voltage, current, temperature, pressure, internal resistance, channel number, step number, and acquisition timestamp, with the sampling period calculated in milliseconds. To maintain data alignment consistency, the system performs strict sorting on the sampling timestamp field. For example, all detection data for channel number 36 will be sorted in chronological order to form a complete sequence, thereby constructing a data block with "channel number + timestamp" as the main index, ensuring query efficiency and curve restoration accuracy in the subsequent archiving process.

[0079] The extracted data is stored in a structured data table with time series as the primary index format. A multi-dimensional index structure is established to support fast retrieval and multi-condition filtering. For the sorted time series data, this invention constructs a unified structured data table. Each row represents a sampling point, and each column corresponds to a parameter dimension, including fields such as voltage, current, temperature, pressure, internal resistance, channel number, step number, acquisition timestamp, equipment group number, and process batch number. To improve data access efficiency, the system simultaneously establishes three types of auxiliary indexes in addition to the main table: channel number index, step number index, and sampling time interval index. For example, when an operator needs to query the temperature change trend of channel number 101 in the third step stage, they only need to quickly locate the data range through the condition combination index. This structured table is designed with a row-column database model, supporting parallel loading of data across batches, effectively supporting the summarization and analysis of subsequent large-scale testing tasks.

[0080] To achieve data synchronization with the Manufacturing Execution System (MES) and the Warehouse Control System (WCS), this invention provides standardized interface protocols and data push services. Considering that battery testing tasks are often deeply integrated with subsequent processes, this invention supports pushing structured testing data to the MES and WCS via a data bus, corresponding to the MES and WCS respectively. This push service uses a standard data structure for encapsulation. The data packets embed core fields such as batch number, channel number, test result summary, anomaly flag, and maximum / minimum value range. It also supports configuring push frequency, failure retry mechanisms, and confirmation receipt logic. For example, when a batch of testing tasks is completed, the system automatically generates 400 corresponding channel data packets. Each data packet contains a summary of key test values ​​for the entire channel process and is pushed to the MES to drive the parameter setting for the next process step. Simultaneously, the WCS can be used to map the physical location of battery cells and link storage instructions, thereby achieving process-level tracking and collaborative material control.

[0081] The host computer system in this invention supports exporting all test data into standard format data files and provides a visualization software interface for curve analysis and filtering. To facilitate subsequent data comparison and quality assessment by operators or process engineers, this invention provides a one-click export function, supporting the export of all test data in batches into standard format data files, including comma-separated text, table, and database snapshot formats. In each file structure, the field order is completely consistent with the structured table, facilitating direct access across different analysis platforms. Simultaneously, this invention also provides an embeddable curve visualization interface, supporting the generation of corresponding voltage, current, temperature, or other parameter variation curves by channel number, step number, or time interval, assisting engineers in identifying process anomalies such as curve breakpoints, abnormal peaks, and voltage drift. Taking channel number 116 as an example, if the current curve shows three short-term spikes in the sixth step, the visualization tool immediately presents this abnormal pattern and exports the corresponding time points and parameters for expert analysis, model annotation, or defect feedback mechanism training.

[0082] After completing the process execution and data aggregation, to further improve the overall consistency and operational stability of channel data within the equipment group, this invention introduces an outlier detection function during the consistency verification process to identify deviations in the detection data of each channel in real time. The principle of this detection function is to dynamically identify abnormal channels or data drift phenomena through statistical distribution characteristics and local change trends, thereby preventing distortion of the overall process results due to hardware noise, sampling jitter, or delay drift in individual channels. The specific steps are as follows: For the voltage data of all channels under the same equipment group, extract the continuous sampled value sequence within the current process cycle to construct a channel data set. Within the current process execution cycle, the host computer reads the real-time voltage data of all channels managed by each central processing unit through the data acquisition module. To ensure the time consistency of the calculation results, this invention specifies that continuous sampled value sequences are extracted within the same time window. The window length can be determined according to the sampling frequency and process time. For example, when the sampling frequency is ten times per second and the process duration is sixty seconds, the sampling sequence of each channel contains six hundred continuous data points. The data sequences from all channels are uniformly organized into a channel dataset, where each row represents the voltage sequence of one channel, and each column represents the voltage value at the same time. For example, the sampled voltage value range of channel number 23 within this window is 3.76V to 3.89V, and the range of channel number 24 is 3.77V to 3.85V. By constructing the channel dataset, a strict time alignment relationship is ensured between the data of different channels, providing a foundation for subsequent statistical feature analysis and residual construction.

[0083] To achieve accurate evaluation of channel stability factors, this invention proposes calculating three key statistical indicators for the data sequence: median, median absolute deviation, and local average rate of change. These three indicators quantify the channel signal characteristics from the perspectives of central trend, dispersion, and short-term fluctuations, respectively. The specific calculation method is as follows: For the voltage values ​​collected by a channel within a specified time window, all sampled values ​​are first sorted from smallest to largest. If the number of samples is odd, the middle value is taken as the median; if it is even, the average of the two middle values ​​after sorting is taken as the median. For example, if the data sequence for channel number five is: 3.74, 3.75, 3.78, 3.81, 3.84, then the median is the third sampled value, 3.78. If the data consists of six points: 3.71, 3.72, 3.74, 3.77, 3.80, 3.81, then the median is the average of the third and fourth values, 3.755.

[0084] Based on the median, the absolute values ​​of the differences between all sampled points of the channel and the median are taken. These absolute values ​​are then used as a new set, and the median is calculated from this set, yielding the median absolute deviation. For example, for a channel with a median of 3.75, the set of absolute differences between the original sequence and the median might be: 0.03, 0.02, 0.05, 0.01, and 0.04. The sorted median of this set is 0.03, which is the median absolute deviation. This indicator can effectively reflect the fluctuation of channel data around the main trend, and its robustness is much higher than that of the standard deviation, making it particularly suitable for voltage signals with outliers or short-term jitter.

[0085] The local average rate of change is used to describe the short-period fluctuations of a channel's sampled data on the time axis. The calculation steps are as follows: Divide the original channel data sequence into several segments of equal length and continuous time, each segment containing a fixed number of sampling points, such as ten points per segment; calculate the average voltage value in each segment; calculate the difference between the average values ​​of two adjacent segments and take their absolute values; average all the absolute values ​​of the differences, which is the local average rate of change of the channel within the current window. For example, if the first segment has an average of 3.75 volts, the second segment has 3.77 volts, and the third segment has 3.76 volts, then the difference in voltage is 0.02 and 0.01, respectively, and the final local average rate of change is 0.015. This indicator reflects the stability of the channel's sampled data fluctuations at small time scales and is an important basis for identifying high-frequency oscillations or jitter behavior in this invention.

[0086] To integrate the above three indicators into a unified channel stability factor, this invention employs a weighted summation method. The weighting coefficients are set based on a comprehensive consideration of the following two dimensions: the distribution pattern of signal stability sensitivity; in the battery detection process, the median absolute deviation is much more sensitive to outlier detection than the median; and the local average rate of change is more sensitive to high-frequency fluctuations. To balance the influence of these three factors, this invention uses historical test data for model training and analysis, finding that the median absolute deviation contributes approximately 40% to the identification of unstable behavior, thus giving it a higher weight; the median and the local average rate of change have similar contributions, each assigned a weight of 30%. This weighting strategy references distributed weight allocation methods used in mature statistical models for signal stability assessment, such as robustness optimization methods and variability sensitivity adjustment mechanisms in signal fusion processes, and is optimized in conjunction with the actual operation of multi-channel equipment. The final settings are: median weight set at 30%, median absolute deviation weight set at 40%, and local average rate of change weight set at 30%.

[0087] Treating the equipment group as a whole, this invention constructs a residual matrix between each channel and other channels based on channel stability factors, and applies the three-times median absolute deviation rule to identify outlier channels. After obtaining the stability factors of all channels, this invention considers all channels within the equipment group as a whole, calculates the difference in stability factors between each pair of channels, and constructs a residual matrix. Each element of the residual matrix represents the absolute value of the stability difference between any two channels. For example, in an equipment group containing sixty-four channels, the residual matrix is ​​sixty-four times sixty-four, and the (5, 20)th element in the matrix represents the numerical value of the stability difference between channel five and channel twenty. Subsequently, the median and median absolute deviation of all non-zero elements in the matrix are calculated, and the "three-times median absolute deviation rule" is applied for outlier determination. If the average residual value of a channel exceeds the overall median plus three times the median absolute deviation, then the channel is determined to be an outlier channel. For example, if the median of the residual values ​​of all channels in the equipment group is 0.06 and the median absolute deviation is 0.04, then the threshold is 0.18. When the average residual value of channel 34 reaches 0.21, it is marked as an outlier channel. This method effectively suppresses the interference of occasional measurement errors, making the anomaly detection more robust.

[0088] For channels marked as outliers, a synchronization wait command is issued, pausing the channel's process until the next consistency check verifies its recovery. When a channel is identified as an outlier, the host computer immediately sends a synchronization wait command to its corresponding central processing unit (CPU). Upon receiving this command, the CPU pauses the execution of the current step for that channel, maintaining the current voltage output or sampling state to prevent abnormal channel data from continuing to enter the main process and affecting the overall data structure. During the pause, the channel continues sampling, but the results are only used for internal state observation and do not participate in the overall calculation. Simultaneously, the outlier channel number, detection time, stability factor value, and residual matrix deviation are recorded in the outlier channel log. For example, if channel number 34 is identified as an outlier at time 14:25, with a stability factor of 0.32 and a residual deviation of 0.21, this record will be entered in the log. Subsequently, when the next consistency verification cycle arrives, the system will recalculate the stability factor and residual value of the channel. If it recovers to the threshold range, the synchronization waiting state will be automatically released, and the channel will rejoin the normal process execution, realizing dynamic closed-loop anomaly monitoring and recovery.

[0089] To address the issue in multi-processor battery testing systems where a central processing unit (CPU) marked as permanently offline due to continuous communication anomalies can lead to lost channel tasks, process interruptions, or decreased testing accuracy, this invention proposes a channel rescheduling strategy during the anomaly repair process. This strategy enables dynamic migration of channels managed by the abnormal CPU, process recovery, and ensures system stability. Based on a real-time constructed graph model, task allocation relationships are dynamically updated to achieve intelligent scheduling optimization. The specific steps are as follows: A node graph of CPU nodes within the device group is constructed, with CPUs as nodes and channel transmission weights as edges. The current channel load, historical error rate, and latency of each CPU are recorded. When a CPU is marked as permanently offline during system operation, the primary task of initiating the channel rescheduling strategy is to construct a graph of the current operating status of each CPU within the device group. Specifically, each CPU is treated as a node in the graph, and the logical connection between channels and CPUs is abstracted as the existence of edges. The initial weight of each edge is dynamically calculated based on three key parameters: current channel load, historical error rate, and task processing latency. The channel load is calculated by real-time statistics of the number of channels currently handled by the central processing unit (CPU). The historical error rate is derived from the ratio of the number of abnormal events generated during task processing by the CPU within a set period to the total number of tasks. Task latency is calculated based on the difference between the step response time and the expected time. By uniformly recording these three types of information, a preliminary map is constructed, laying a structured data foundation for subsequent path evaluation and node selection. For example, if the CPU is numbered eight, currently handles twenty-one channels, has a historical error rate of 3.5%, and an average processing latency of 0.75 seconds, then the initial value of the corresponding node edge weight will be reflected as a mapping value of this comprehensive indicator.

[0090] The dynamic weights of each edge in the graph are constructed using a channel load balancing factor and a historical error factor. Based on the graph structure built in the previous step, this invention further dynamically adjusts the edge weights by introducing two key indicators: the channel load balancing factor and the historical error factor, to construct a composite weight model for the edges. The channel load balancing factor is calculated as follows: the ratio between the number of channels currently managed by the central processing unit and its maximum allowed number of channels is calculated; if this ratio is greater than a set threshold, it indicates that the current load is close to saturation, and the edge weight coefficient increases. The historical error factor is calculated by statistically analyzing the frequency of abnormal events occurring in the central processing unit within a specified historical period and linearly mapping it to the ratio of the total number of processing tasks during the same period. The mapping result is then converted into a standardized score representing its operational stability. Both factors are assigned empirical weights to form the final composite weight of the edge; the lower the weight, the stronger the node's ability to accept new channels. For example, the central processing unit numbered nine has a channel load ratio of 70%, a historical error rate of 4.2%, and a comprehensive score coefficient of 0.81, which is better than the score coefficient of 0.94 of the central processing unit numbered ten. Therefore, it is given higher priority in the scheduling candidate pool.

[0091] For central processing units (CPUs) marked as abnormal, the node is removed from the graph, and a shortest path calculation algorithm is initiated to find a new CPU whose channel can be mapped. After completing the graph update and weight labeling, this invention immediately performs channel migration path reconstruction. First, CPU nodes marked as permanently offline by the system are removed from the graph structure, completely removing their mapping relationship with all channels. Then, for all channels managed by the CPU, the shortest path calculation algorithm is initiated one by one to find the target CPU with the minimum comprehensive edge weight to achieve channel remapping. This shortest path calculation process traverses all remaining nodes based on the weight matrix, with the optimization objective of minimizing the impact of the new migration path on the overall process stability. For example, channel number 47 was originally bound to CPU number 8. After it went offline, the graph algorithm found that the edge weight of CPU number 11 was only 0.63, which was much lower than the edge weights of other candidate nodes of 0.72 and 0.80. Finally, the system remapped channel number 47 to CPU number 11, completing the path reconstruction.

[0092] Under the new mapping relationship, the scheduling matrix is ​​regenerated, and process parameter migration is performed, including step parameters, curve sampling rules, and synchronization timestamps. After completing the mapping reconstruction of all channels, this invention enters the scheduling matrix reconstruction stage. First, based on the latest channel and central processing unit mapping results, the system automatically reconstructs the channel scheduling matrix, transferring the process instructions, battery detection steps, protection thresholds, and operation logic required for each channel to the new central processing unit. Next, to ensure that the migration process does not cause execution misalignment, all step parameters will regenerate the process start identifier, and the curve sampling rules and synchronization timestamps will be uniformly calibrated according to the current global time base of the equipment group. Taking channel number 47 as an example, the original execution curve sampling interval was 0.1 seconds. After the migration, the sampling start time will be reset to the current global time plus 0.5 seconds to ensure that it is in a synchronized execution state with other channels. Subsequently, the system executes the process command, and all channels synchronously start consistency verification. If there is no deviation, the channel rescheduling is considered complete, and the overall equipment group process returns to normal operation.

[0093] The above algorithms or formulas are all dimensionless and numerical calculations, and the results are obtained by software simulation based on a large amount of collected data to obtain the most recent real-world results. The preset parameters are set by those skilled in the art according to the actual situation.

[0094] It should be understood that in the various embodiments of this application, the order of the above-mentioned processes does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0095] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

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

[0097] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A battery detection method based on multi-central processing unit merging, characterized in that, The method comprises the following steps: Device group configuration: in the host computer system, based on the requirements of the battery detection process for the number and parameters of the channels, a plurality of central processing units are configured as a device group, and a mapping relationship between the central processing units and the channels is established, so that the plurality of central processing units are logically regarded as a single device unit and are uniformly managed and controlled; Connection state detection and initialization: the host computer establishes a communication connection with each central processing unit through the transmission control protocol, and periodically detects the connection state; when any central processing unit is disconnected, the system automatically attempts to reconnect multiple times, and after a successful reconnection, performs time synchronization, channel mapping confirmation and process identification calibration on the central processing unit, to ensure that the initial state of the central processing unit is consistent with the device group; Process issuing and parallel execution: the host computer issues a preset battery detection process in the form of a process instruction to each central processing unit in the device group in parallel through a multi-thread mechanism, and distributes the instruction according to the channel mapping relationship, to ensure that all central processing units execute the corresponding process in the same logical time sequence; State acquisition and consistency verification: during the process execution, the host computer acquires the execution state, process information and detection data of each central processing unit in real time, and compares the execution progress of each central processing unit in the device group according to a set consistency judgment rule; when it is found that the execution state of a certain central processing unit deviates from that of other central processing units, the system puts the central processing unit into a synchronization waiting state and suspends its process execution, to prevent process misplacement or data anomaly; Abnormality repair and process reconstruction: for the central processing unit in the synchronization waiting state, the host computer continuously detects its state change; when the central processing unit completes communication recovery or abnormality elimination, the host computer reissues the uncompleted process instruction and protection parameters of the central processing unit according to its last consistency verification record, and calibrates its execution progress and current configuration state; After the repair is completed, the central processing unit automatically exits the synchronization waiting state and rejoins the process execution of the device group; Process completion judgment and data summarization: when all central processing units complete the corresponding detection process and pass the final cross verification, the host computer records the process completion state, uniformly summarizes the detection data of all channels, and stores the data in a structured manner according to the channel number and time stamp; In the consistency verification process, an outlier detection function is introduced to judge the deviation behavior of the channel data, and the specific steps are as follows: Step one: for the voltage data of all channels under the same device group, the continuous sampling value sequence in the current process period is extracted to construct a channel data set; Step two: the median, median absolute deviation and local average change rate of each channel data sequence are calculated, and after normalization processing, a weighted sum is performed to generate a channel stability factor; Step three: based on the channel stability factor, a residual matrix is constructed between each channel and other channels as a whole, and a three-fold median absolute deviation rule is applied to mark the outlier channels; Step four: for the channels marked as outliers, a synchronization waiting command is issued to suspend the process of the channels, until the next consistency verification verifies that the channels return to normal; In the abnormal repair process, the channel rescheduling strategy is introduced, including: Construct a device group central processing unit node graph, with central processing unit as node and channel transmission weight as edge, record the current channel load, historical error rate and delay of each central processing unit; Use channel load balancing factor and historical error factor to construct the dynamic weight of each edge in the graph, the channel load balancing factor is obtained by calculating the ratio of the number of channels currently borne by the central processing unit to its maximum bearing upper limit, the historical error factor is obtained by mapping the frequency of abnormal events of the central processing unit in a specified historical period to the total number of tasks, and the standardized score value representing the running stability of the central processing unit is obtained; For the central processing unit marked as abnormal, delete the node from the graph, and start the shortest path calculation algorithm to find the new central processing unit that can map the channel; Under the new mapping relationship, the scheduling matrix is regenerated, and the process parameter migration is performed, including process parameter, curve sampling rule and synchronization timestamp; After rebuilding the communication channel and mapping index, the process is reissued and the test process is entered, if all channels pass the consistency verification, the process execution of the whole device group is restored.

2. The battery detection method based on the combination of multiple central processing units according to claim 1, wherein, The mapping relationship between each central processing unit and channel is bound through index dictionary, and static mapping table and dynamic mapping cache are established at the beginning, the mapping table records the central processing unit number corresponding to each channel number, the physical index of the channel in the central processing unit, the channel alias and the serial number information in the device group, the mapping relationship is added, adjusted and named by the user through the visual configuration interface, and is used for accurate instruction delivery in the process sending process.

3. The battery detection method based on the combination of multiple central processing units according to claim 1, wherein, The connection state detection adopts a multiple polling mechanism based on time window, including: Set the detection times threshold in a fixed time interval, if any response is still not obtained, mark the central processing unit as offline state; Once marked as offline, enter the communication recovery logic process, including releasing the old connection, rebuilding the transmission control protocol session, sending the handshake command and comparing the returned central processing unit unique identification code, if the connection is successful, the initialization step is performed, otherwise the fault log is recorded and an alarm is given.

4. The battery detection method based on the combination of multiple central processing units according to claim 1, wherein, The multi-thread mechanism refers to: The host computer binds a global process unique identification number, a channel unique index number and a timestamp information for each process instruction, and uses a preset distributed thread pool model for load balancing in the process of issuing.

5. The battery detection method based on the combination of multiple central processing units according to claim 4, wherein, The consistency judgment rules include three types of indexes: execution state comparison, step identification comparison and process time alignment, including but not limited to: The difference of step number of all central processing units in the same device group shall not exceed one, if any central processing unit lags behind two or more steps, the state deviation is marked; The difference of current step execution time between all central processing units shall not exceed the set threshold time, otherwise the state locking process is performed; If the data timestamp returned by any channel is earlier than the group time reference n seconds, it is marked as abnormal data, and the channel is forced to pause.

6. The battery detection method based on the combination of multiple central processing units according to claim 5, wherein, During the repair process, if a central processing unit is marked as permanently offline due to consecutive communication failures, an automatic process reconstruction mechanism will be activated. This mechanism will automatically redistribute the channel processes handled by the abnormal central processing unit to other available central processing units based on the number of remaining central processing units in the current device group, channel load conditions, and mapping table backups. It will also regenerate the instruction scheduling diagram and distribution matrix.

7. The battery detection method based on the combination of multiple central processing units according to claim 5, wherein, During the completion judgment process, the state information of all central processing units is cross-verified three times. The first verification is a step execution state comparison, the second verification is a channel completion flag comparison, and the third verification is a curve data integrity check. Under the condition that all verifications are passed, the overall process is marked as completed. The curve data verification includes the number of sampling points, the maximum and minimum value interval, the sampling time span, and the sampling interval of each channel. If any channel curve has breakpoints, mutations, or no data, the process will not be settled and will be marked as a failure with abnormal detailed data points recorded for analysis and tracing.

8. The battery detection method based on the combination of multiple central processing units according to claim 7, wherein, In the data summary process after the completion of the process, the detection data of each channel is structured and archived with time series as the main index.

Images