Battery management system automatic test system based on cloud platform

Abstract

The invention discloses an automatic test system of a battery management system based on a cloud platform, and relates to the technical field of battery test management, the system determines the storage suitability by quantifying the characteristics of data, and dynamically adjusts the encryption strength in combination with the sensitivity coefficient of a test scene, thereby ensuring that high-sensitivity data obtains targeted safety guarantee, and improving the reliability of the test. Resource waste caused by excessive encryption of common data is avoided, accurate matching of storage resources and data security requirements is realized, and the storage security and resource utilization efficiency of the test data of the battery management system are improved; and quantizing the feature integrating degree of the corrected historical data set and the existing data of each storage area through cosine similarity, and comprehensively determining a target storage area in combination with the performance and resource state of the storage area. In this way, linkage adaptation of data characteristics-storage performance-resource states is achieved, and the problem that in traditional storage, data and regional characteristics are not matched, so that the read-write efficiency is low or resources are idle is solved.

Description

Technical Field

[0001] This invention relates to the field of battery test management technology, and more specifically, to an automated test system for battery management systems based on a cloud platform. Background Technology

[0002] In the field of battery management system testing, as the new energy industry continues to raise its requirements for battery performance and safety, a large amount of test data is generated during the testing process, including key parameters such as charge and discharge efficiency, voltage equalization, and SOC estimation error. However, existing technologies lack the ability to coordinate and manage data based on cloud platforms. Test data is mostly stored locally on various devices, and the allocation of storage areas lacks specificity—it does not adapt storage resources to the sensitive characteristics of the data itself (such as the degree of safety impact of voltage and SOC-related parameters). At the same time, encryption strength is mostly set to a fixed value, which makes it difficult to guarantee the security requirements of highly sensitive data and easily leads to the waste of storage resources due to excessive encryption of ordinary data, resulting in an overall imbalance between storage security and resource utilization efficiency.

[0003] Existing correction methods for BMS test data retesting have significant limitations. When error correction is needed for historical test data, a broad approach of full adjustment is often used instead of targeted correction for specific abnormal parameters such as SOC error or voltage balance anomalies. This not only increases unnecessary computational overhead but may also distort normal data. Furthermore, current retesting processes do not effectively record parameter modification characteristics (such as the amount of bytes modified and the frequency of modification), failing to provide reliable support for subsequent data optimization. This makes historical test data susceptible to inaccuracies due to changes in timeliness and environmental conditions, hindering the formation of a continuously iterative test data management system.

[0004] Regarding dynamic matching of storage areas, existing technologies mostly rely on a single dimension (such as remaining capacity) to determine data storage location, failing to establish a linkage and adaptation mechanism between "data characteristics, storage performance, and resource status." For example, without quantifying the compatibility between data characteristics (such as voltage fluctuations and current change rates) and existing data in the storage area, and without comprehensively considering the throughput capacity and remaining resource status of the storage area, frequently updated dynamic data may be stored in low-throughput storage areas, while static data occupies high-specification storage resources, resulting in low read / write efficiency or idle storage resources. This fails to form a complete closed loop of "testing-storage-optimization," making it difficult to meet the needs of dynamic management of BMS test data. Summary of the Invention

[0005] In view of the shortcomings of existing technologies, the purpose of this invention is to provide an automated testing system for battery management systems based on a cloud platform.

[0006] To achieve the above objectives, the present invention provides the following technical solution: The cloud-based automated testing system for battery management systems includes a main cycle test data generation module, a battery management storage retest analysis module, an encrypted storage execution module, and a test data retest module. The main cycle test data generation module is used to control the cloud platform to collect the battery pack's operating parameters every time it goes through a main cycle, synchronously generate multiple system node test logs, and summarize all system node test logs within the main cycle to form the main cycle test dataset. The battery management storage retest analysis module generates a main cycle test dataset and queries the historical test count of the corresponding battery pack. If the historical test count of the battery pack is 0 or 1, it determines that the storage adaptation value and key strength of the main cycle test dataset need to be calculated and then dynamically encrypted and stored. Otherwise, it determines that retest optimization needs to be performed based on the main cycle test dataset. The encrypted storage execution module is used to calculate the storage adaptation value and key strength of the main cycle test dataset, and then perform dynamic encrypted storage. The test data retesting module is used to perform retesting and optimization based on the main cycle test dataset.

[0007] Furthermore, the system node test logs include charge / discharge efficiency ηt, voltage equalization ΔVt, and SOC estimation error Et.

[0008] Furthermore, the adaptation value and key strength of the main cycle test dataset are calculated, and then dynamically encrypted and stored. Specifically, the standardized voltage value Vi, standardized current value Ii, standardized SOC estimate Si, and standardized SOC estimate error Ei corresponding to each sub-cycle of the main cycle test dataset are obtained, and then stored using the formula... Calculate the storage adaptation value P, where n is the total number of sub-periods corresponding to the main period test dataset, and i represents the index of the corresponding sub-period. , , , These are the weight vectors for voltage, current, SOC, and SOC battery pack error, respectively; high and low storage adaptation values ​​are set, when... Matches "high-security storage area"; when Matching "low-cost storage area", when When the value falls between the high and low storage adaptation values, a "high-throughput storage area" is matched; the key strength is further calculated, the encryption algorithm is determined based on the key strength, and the encrypted master cycle test dataset is stored in the corresponding storage area.

[0009] Furthermore, retesting optimization is performed based on the main cycle test dataset. Specifically, the current main cycle test dataset is marked as the updated test dataset. The most recently stored main cycle test dataset for the corresponding battery pack is retrieved from the storage area and marked as the historical test dataset. Abnormal parameters of the historical test dataset are corrected based on the updated test dataset. After each correction, the byte modification amount of each feature parameter is recorded, and the change test value F is further calculated. A change test threshold is set. When the change test value F < the change test threshold, the historical test dataset is still stored in the original area. When the changed test value F is greater than or equal to the changed test threshold, the storage area needs to be rematched.

[0010] Furthermore, through the formula Calculate the changed test value F; , , , , All are weighting coefficients; This refers to the number of times the historical test dataset of the current battery pack has been decrypted within the statistical period. This represents the average time taken for each decryption operation within the statistical period. This represents the cumulative number of times the storage area of ​​the current historical test dataset has been adjusted throughout history. This is the average of the "byte modification amount" of all corrected feature parameters within a single main cycle; This represents the average number of modifications per unit time for all corrected characteristic parameters within a single main cycle.

[0011] Furthermore, cosine similarity is used to calculate the similarity q between the feature matrix of the corrected historical test dataset and the existing data feature matrix of each storage region. The feature matrix includes parameters such as voltage fluctuation value, current change rate, and SOC correction amount. Then, the optimized storage value Z of each storage region is calculated using the following formula: ; , , All are optimization coefficients; This refers to the throughput of the storage area; Given the remaining capacity of the storage area, select the storage area with the largest Z as the target storage area for the historical test dataset.

[0012] Compared with the prior art, the present invention has the following beneficial effects: The system of this invention determines storage suitability by quantifying the characteristics of the data itself and dynamically adjusts the encryption strength in combination with the sensitivity coefficient of the test scenario. This ensures that highly sensitive data receives targeted security protection while avoiding resource waste caused by excessive encryption of ordinary data. It achieves a precise match between storage resources and data security requirements, and improves the security and resource utilization efficiency of battery management system test data storage. Using the current updated test dataset as a reference, the abnormal parameters of the historical test dataset are corrected in a targeted manner, rather than being adjusted in their entirety. This correction method can not only accurately eliminate errors in historical data (such as SOC error and voltage equalization abnormality), but also provide data support for subsequent optimization by recording parameter modification characteristics (byte modification amount, modification frequency). This effectively solves the problem of insufficient accuracy of historical test data due to timeliness or environmental changes, and lays the foundation for iterative optimization of battery management system test data. By quantifying and correcting the historical dataset with cosine similarity to determine the feature fit between it and the existing data in each storage region, and combining this with storage region performance (throughput) and resource status (remaining capacity), the target storage region is comprehensively determined. This approach achieves coordinated adaptation of "data features - storage performance - resource status," avoiding the problems of low read / write efficiency or resource idleness caused by mismatch between data and region characteristics in traditional storage. It forms a closed loop of "testing - storage - optimization," further improving the dynamic adaptability and overall efficiency of battery management system test data management. Attached Figure Description

[0013] Figure 1 This is a schematic diagram of the principle of the present invention; Figure 2 This is a flowchart illustrating the principle of retest optimization based on the main cycle test dataset. Detailed Implementation

[0014] Reference Figures 1-2 The cloud-based automated testing system for battery management systems includes a main cycle test data generation module, a battery management storage retest analysis module, an encrypted storage execution module, and a test data retest module.

[0015] The main cycle test data generation module is used to control the cloud platform to collect the battery pack's operating parameters every main cycle (the cycle length of the main cycle is set according to the battery pack's testing requirements, and each main cycle is divided into multiple sub-cycles with equal time intervals). It synchronously generates multiple system node test logs (each sub-cycle corresponds to one system node test log). The system node test logs include charge and discharge efficiency ηt, voltage equalization ΔVt, and SOC estimation error Et. All system node test logs within the main cycle are summarized to form the main cycle test dataset.

[0016] The charge / discharge efficiency ηt is obtained as follows: Within each sub-cycle, the battery pack's charge / discharge current data is collected via a cloud platform, and the charged and discharged capacity within that sub-cycle are calculated. The charged capacity within a sub-cycle is the integral of the charging current over time (i.e.,...). , (where the charging current is the charge output during the sub-cycle is the integral of the discharge current over time during the discharge phase) , (where η is the discharge current); the charge / discharge efficiency ηt is obtained through the formula... (Charging scenario) or (Discharge scenario) Calculated.

[0017] The voltage balance ΔVt is obtained as follows: Within each sub-cycle, the real-time voltage values ​​of all individual cells in the battery pack are acquired synchronously (e.g., if a battery pack contains 16 cells, 16 voltage data points are collected); the maximum value is extracted from the individual cell voltage data of that sub-cycle. and minimum value Through formula The voltage balance ΔVt is calculated.

[0018] The method for obtaining the SOC estimation error Et is as follows: Within each sub-cycle, the SOC estimation value output by the battery pack itself is obtained. (i.e., the percentage of remaining battery charge calculated in real time by the battery pack); on the other hand, the actual SOC value of the battery within this sub-cycle is obtained through offline detection methods (such as capacity discharge method, internal resistance method, etc.). The SOC estimation error Et is calculated using the formula... The calculations show that the BMS's estimation error regarding the remaining power capacity is incorrect.

[0019] The battery management storage retest analysis module generates a master cycle test dataset and queries the historical test count of the corresponding battery pack (historical test refers to whether the battery pack has undergone master cycle operation parameter collection and system node test log generation). If the historical test count of the battery pack is 0 or 1, the module calculates the storage adaptation value and key strength of the master cycle test dataset and then performs dynamic encryption storage. Otherwise (historical test count is greater than or equal to 2), the module performs retest optimization based on the master cycle test dataset.

[0020] The encrypted storage execution module calculates the storage adaptation value and key strength of the main cycle test dataset, and then performs dynamic encrypted storage. Specifically, it obtains the standardized voltage value Vi, standardized current value Ii, standardized SOC estimate Si, and standardized SOC estimate error Ei for each sub-cycle of the main cycle test dataset, and uses the formula... Calculate the storage adaptation value P, where n is the total number of sub-periods corresponding to the main period test dataset, and i represents the index of the corresponding sub-period. , , , These are the weight vectors for voltage, current, SOC, and SOC battery pack error, respectively (set according to the data sensitivity level of the battery pack's battery management system; for example, voltage data affects battery safety). SOC error affects battery life estimation. ,and ); Set storage adaptation high value and storage adaptation low value (storage adaptation high value is higher than storage adaptation low value), when Matches "high-security storage area"; when Matching "low-cost storage area", when When the value falls between high and low storage fit, the "high-throughput storage area" is matched (the storage area is divided according to the range of P values: when P∈[0.7,1.0], the "high-security storage area" is matched (storing highly sensitive data, such as datasets with SOC error ≤5%); when P∈[0.4,0.7), the "high-throughput storage area" is matched (storing frequently updated data, such as vehicle road test data); when P∈[0,0.4), the "low-cost storage area" is matched (storing static test data, such as laboratory data left to stand at room temperature)); further, the formula is used to... Calculate the key strength ; , All are key strength coefficients ( Based on the principle of prioritizing data characteristics and supplementing with scenario-sensitive data, The value can be 0.6. The value can be 0.4 and can be dynamically adjusted according to the security requirements of specific scenarios. The data sensitivity coefficient is set according to the scenario label, such as H=0.9 for batteries that are prone to lithium plating in the "low temperature charging and discharging" scenario and H=0.3 for the "room temperature standing" scenario. The key strength S corresponds to different encryption algorithms: when S≥0.8, AES-256 encryption is used; when 0.5≤S<0.8, AES-192 encryption is used; when S<0.5, AES-128 encryption is used. Then the encrypted main cycle test dataset is stored in the corresponding storage area.

[0021] The standardized voltage value Vi is obtained by selecting a sub-cycle corresponding to the main cycle test dataset and obtaining the average voltage of all individual cells within that sub-cycle. Through formula Calculate the standardized voltage value Vi; This is the maximum allowable single-cell voltage of the battery pack (set according to the battery's nominal parameters). This is the minimum allowable single-cell voltage for the battery pack.

[0022] The standardized current value Ii is obtained as follows: Select a sub-cycle corresponding to the main cycle test dataset, and obtain the real-time current at the beginning and end of that sub-cycle (recorded as positive during charging and negative during discharging). Calculate the average of the start and end real-time currents to obtain the original current value. Through formula Calculate the standardized voltage value Vi; The maximum allowable charging current for the battery pack. This is the maximum allowable discharge current.

[0023] The standardized SOC estimate Si is obtained by: obtaining a sub-period corresponding to the main period test dataset, and then obtaining the SOC estimate for that sub-period. Through formula The standardized SOC estimate Si was calculated.

[0024] The standardized SOC estimation error Ei is obtained as follows: Obtain a sub-period corresponding to the main period test dataset, and then obtain the SOC estimation error Et corresponding to that sub-period using the formula... The standardized SOC estimation error Ei is calculated.

[0025] The test data retesting module optimizes retesting based on the main cycle test dataset. Specifically, it marks the current main cycle test dataset as the updated test dataset, retrieves the most recently stored main cycle test dataset for the corresponding battery pack from storage, and marks the retrieved main cycle test dataset as the historical test dataset. It then corrects abnormal parameters in the historical test dataset based on the updated test dataset (setting abnormal thresholds (SOC error > 5%, voltage equalization ΔVt > 0.2V). If the SOC error St in the historical test dataset exceeds the threshold, it calculates the correction deviation ΔEt (ΔEt = estimated SOC value St of the historical test dataset - value of the updated test dataset). ,in, To update the test dataset (using the offline capacity discharge method to obtain the true SOC), abnormal SOC values ​​in the historical test dataset are corrected to St' = St - ΔEt. If the voltage equalization ΔVt exceeds the threshold, the historical data's ΔVt is similarly corrected based on the actual ΔVt of the updated test dataset (the measured voltage equalization of the updated test dataset). After each correction, the byte modification amount ΔBt (e.g., voltage data corrected from 2 bytes to 4 bytes, ΔBt = 2) and modification frequency Ft (e.g., a certain SOC data is corrected 3 times in 1 hour, Ft = 3) for each feature parameter (voltage, current, SOC, etc.) are recorded using the formula. Calculate the changed test value F; , , , , All are weighting coefficients, and Used to weight the impact of different parameters on the "Change Test Value F", reflecting the importance and priority of each parameter; Default value: (Decryption of frequency weight) (Weight of average decryption time) (Storage change frequency weight) (Average byte modification weight) (Weight of average modification frequency); This refers to the number of times the current battery pack's historical test dataset has been decrypted within the statistical period (decryption triggered by operations such as retesting and verification). This represents the average time taken for each decryption operation within the statistical period (the time from initiating a decryption request to obtaining plaintext data). The cumulative number of times the storage area of ​​the current historical test dataset has been adjusted in history (initially 0, incremented by 1 for each adjustment); It is the average of the "byte modification" of all corrected characteristic parameters (voltage, current, SOC, etc.) within a single main cycle; This is the average of the "number of modifications per unit time" for all corrected characteristic parameters within a single main cycle (e.g., voltage data is corrected twice per hour, current data is corrected once per hour, then...). Set a change test threshold. When the change test value F < the change test threshold, it indicates that the data modification frequency is low and the stability is high. The historical test dataset is still stored in the original area.

[0026] When the change test value F is greater than or equal to the change test threshold, it indicates that the data is highly dynamic and the storage area needs to be rematched.

[0027] At this point, the similarity q between the feature matrix of the corrected historical test dataset and the existing data feature matrix of each storage region is calculated using cosine similarity. The feature matrix includes parameters such as voltage fluctuation value, current change rate, and SOC correction amount. Then, the optimized storage value Z of each storage region is calculated using the following formula: ; , , All are optimization coefficients (based on the principle of prioritizing data feature matching, followed by storage performance, and supplemented by resource availability, the optimization coefficient allocation can be as follows:) , , ); The throughput of the storage area over the past 24 hours (e.g., high-throughput storage area Tr=80MB / s). The remaining capacity of the storage area is defined (e.g., the remaining capacity of the high-security storage area G = 500GB). The storage area with the largest Z is selected as the target storage area for the historical test dataset, thereby achieving dynamic optimization of the storage area.

[0028] The above formulas are all dimensionless calculations. The formulas are derived from software simulations based on a large amount of collected data to obtain the most recent real-world results. The preset parameters in the formulas are set by those skilled in the art according to the actual situation.

[0029] The above embodiments can be implemented, in whole or in part, by software, hardware, firmware, or any other combination thereof. When implemented using software, the above embodiments can be implemented, in whole or in part, as a computer program product. The computer program product includes one or more computer instructions or computer programs. When the computer instructions or computer programs are loaded or executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that includes one or more sets of available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium. A semiconductor medium can be a solid-state drive.

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

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

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

[0033] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0034] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0035] 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 cloud platform based battery management system automated testing system, characterized in that, The application relates to a battery test data storage method and system. The main cycle test data generation module is used for controlling the cloud platform to collect the operation parameters of the battery pack every time a main cycle is experienced, synchronously generating a plurality of system node test logs, collecting all the system node test logs in the main cycle, and forming a main cycle test data set. The battery management storage retest analysis module is used for inquiring the historical test times of the corresponding battery pack every time a main cycle test data set is generated. The encryption storage execution module is used for calculating the storage adaptation value and the key strength of the main cycle test data set and then performing dynamic encryption storage. The test data retest module is used for retest optimization based on the main cycle test data set.

2. The cloud platform based battery management system automated testing system of claim 1, wherein, The system node test log contains the charge-discharge efficiency eta, the voltage balance degree delta Vt and the SOC estimation error Et.

3. The cloud platform based battery management system automated test system of claim 1, wherein, The calculation of the storage adaptation value and the key strength of the main cycle test data set is further dynamically encrypted and stored, and the specific process is as follows: the standardized voltage value Vi, the standardized current value Ii, the standardized SOC estimation value Si and the standardized SOC estimation error Ei corresponding to each sub-cycle of the main cycle test data set are obtained, and the storage adaptation value P is calculated through the formula The total number of sub-cycles corresponding to the main cycle test data set is n, i represents the serial number of the corresponding sub-cycle, 、 、 、 The weight vectors of voltage, current, SOC and SOC battery error are respectively Setting a storage adaptation high value and a storage adaptation low value, matching a "high security storage area" when , matching a "low cost storage area" when , matching a "high throughput storage area" when between the storage adaptation high value and the storage adaptation low value; further calculating a key strength, determining an encryption algorithm based on the key strength, and storing the encrypted master periodic test data set to the corresponding storage area.

4. The cloud platform based battery management system automated testing system of claim 1, wherein, The retest optimization based on the main cycle test data set is as follows: the current main cycle test data set is marked as an updated test data set, the latest stored main cycle test data set of the corresponding battery pack of the main cycle test data set is taken out from a storage area, the taken-out main cycle test data set is marked as a historical test data set, the historical test data set is modified according to the updated test data set, the byte modification amount of each characteristic parameter is recorded after each modification, and a changed test value F is further calculated. When the changed test value F is less than the changed test threshold, the historical test data set is still stored in the original area. When the changed test value F is greater than or equal to the changed test threshold, the storage area needs to be matched again.

5. The cloud platform based battery management system automated testing system of claim 4, wherein, The changed test value F is calculated by the formula , , , , are weight coefficients; is the number of decryption times of the current battery pack historical test data set in the statistical period; is the average value of the time consumption of each decryption operation in the statistical period; is the cumulative number of times of adjusting the storage area in the history of the current historical test data set; is the average value of the "byte modification amount" of all modified characteristic parameters in a single main period; is the average value of the "modification times per unit time" of all modified characteristic parameters in a single main period.​ 6. The cloud platform based battery management system automated testing system of claim 4, wherein, The cosine similarity is used to calculate the similarity q of the feature matrix of the historical test data set after correction and the existing data feature matrix of each storage area, and the feature matrix includes voltage fluctuation value, current change rate, SOC correction amount and other parameters; then the optimized storage value Z of each storage area is calculated, and the formula is: ; , , are all optimization coefficients; is the throughput rate of the storage area; is the remaining capacity of the storage area, and the storage area with the maximum Z is selected as the target storage area of the historical test data set.

Images