Battery test data processing methods, devices, equipment, media, and procedures.

Abstract

This application relates to the field of battery technology, and discloses a method, apparatus, device, medium, and program product for processing battery test data. The method includes: generating multiple data tables with interrelationships based on battery test data corresponding to a target test item; determining data labels corresponding to each feature dimension in the battery test data, whereby the data labels represent the continuity of the corresponding feature dimensions; establishing a data warehouse model corresponding to the target test item based on the multiple data tables; and generating scenario analysis data corresponding to the target test item based on each feature dimension and its corresponding data labels, whereby the scenario analysis data represents the chart types generated for different data analysis scenarios. This application can reduce redundant data, provide efficient and convenient data query services, improve the efficiency of battery test data analysis and chart generation, reduce battery R&D costs, and reduce the difficulty of analyzing massive amounts of battery test data.

Description

Technical Field

[0001] This application relates to the field of battery technology, specifically to a method, apparatus, equipment, medium, and program product for processing battery test data. Background Technology

[0002] Batteries require testing in many scenarios during production and use, such as testing cycle life, capacity, overcharge, over-discharge, short circuit, water immersion, and drop tests. Battery testing generates a large amount of test data with numerous fields and varying dimensions, making it difficult for users to directly utilize the data. Furthermore, traditional data processing methods suffer from excessive load when handling massive amounts of battery test data, leading to slow system response, sluggish visualization chart generation, and even service interruptions, impacting data analysis efficiency and user experience.

[0003] The above statements are for the purpose of providing background information in relation to this application only and do not necessarily constitute prior art. Summary of the Invention

[0004] In view of the technical problems existing in the above-mentioned related technologies, this application provides a method, apparatus, device, medium, and program product for processing battery test data.

[0005] The first aspect of this application provides a method for processing battery test data, including:

[0006] Based on the battery test data corresponding to the target test items, generate multiple data tables that are related to each other;

[0007] Based on each feature dimension in the battery test data, a data label corresponding to each feature dimension is determined, and the data label is used to characterize the continuity of the corresponding feature dimension.

[0008] A data warehouse model corresponding to the target test item is established based on the multiple data tables; and, based on each feature dimension and the data labels corresponding to each feature dimension, scenario analysis data corresponding to the target test item is generated, wherein the scenario analysis data represents the chart types generated corresponding to different data analysis scenarios.

[0009] In this embodiment, a data warehouse model is established based on a large amount of battery test data corresponding to the target test items. This reduces redundant data in the battery test data. Subsequently, the data warehouse model can provide efficient and convenient data query services, effectively improving the query and processing efficiency of battery test data. Data tags are used to identify the continuity of feature dimensions. Scenario analysis data is generated based on these feature dimension data tags, which helps improve the efficiency of data analysis and chart generation in different data analysis scenarios. This provides efficient, specific scenario analysis, reduces ineffective generalization requirements, lowers battery R&D costs and battery test data analysis costs, and reduces the difficulty of analyzing massive amounts of battery test data. This allows users lacking data analysis experience to conveniently and efficiently analyze battery test data.

[0010] In some embodiments of this application, generating multiple data tables with correlations based on battery test data corresponding to the target test item includes:

[0011] Perform data cleaning on the battery test data corresponding to the target test items;

[0012] Based on the table granularity information corresponding to the target test item and the battery test data after data cleaning, multiple data tables are generated. The table granularity information is used to record the preset granularity of different data tables corresponding to the target test item.

[0013] The same association key is stored in at least two of the multiple data tables, and the association key is used to establish an association relationship between the at least two data tables.

[0014] In the above embodiments, data cleaning effectively reduces abnormal and duplicate data in battery test data, thereby reducing the storage space occupied by the battery test data. The cleaned battery test data is more standardized, which helps improve the accuracy of subsequent analysis and processing based on it. Generating multiple related data tables based on the cleaned battery test data effectively reduces data redundancy and the storage space occupied by the battery test data corresponding to the target test items. Furthermore, the multiple related data tables provide more efficient data query services.

[0015] In some embodiments of this application, determining the data label corresponding to each feature dimension based on each feature dimension in the battery test data includes:

[0016] The feature data under the first feature dimension are obtained from the battery test data; the first feature dimension is any one of the feature dimensions.

[0017] Determine the temporal distribution pattern of each feature data under the first feature dimension;

[0018] Based on the temporal distribution patterns of the aforementioned feature data, data labels are assigned to the first feature dimension.

[0019] This embodiment determines the temporal distribution pattern of each feature data point within a feature dimension, and assigns data labels to the feature dimensions accordingly. This allows for the rapid determination of the temporal distribution pattern of data within a feature dimension based on its data labels. This facilitates subsequent determination of the effectiveness of different feature dimension combinations and the appropriate chart types for different feature dimension combinations, thereby providing users with scenario-specific processing services for various data analysis scenarios, improving the efficiency of battery test data processing, and reducing the difficulty of battery test data processing.

[0020] In some embodiments of this application, generating scene analysis data corresponding to the target test item based on each feature dimension and the data labels corresponding to each feature dimension includes:

[0021] Based on each feature dimension and the corresponding data label, the feature dimensions are arranged and combined to obtain a variety of data analysis scenario combinations; each data analysis scenario combination includes at least one feature dimension and the corresponding data label.

[0022] From the various combinations of data analysis scenarios, select the target data analysis scenario combinations that can display the analysis results in chart form;

[0023] Determine the appropriate chart type for each of the target data analysis scenario combinations;

[0024] The scenario analysis data is generated based on the combination of target data analysis scenarios and the corresponding chart types.

[0025] This embodiment, based on feature dimensions and their corresponding data labels, filters out target data analysis scenario combinations that can display analysis results graphically, and determines the appropriate chart types for each target data analysis scenario component. This provides a richer set of data analysis scenarios, offering data analysis services to users on a scenario-by-scenario basis, reducing ineffective generalization requests, and significantly improving the convenience of data analysis and lowering the barrier to entry for users. Furthermore, by analyzing data through scenarios, the appropriate chart types for different target data analysis scenarios can be clearly identified. When providing scenario analysis services, it is easy to use suitable visualization charts to display analysis results, improving the efficiency of battery test data analysis and the effectiveness of result presentation.

[0026] In some embodiments of this application, the method further includes:

[0027] The user-selected target data analysis scenario is determined through the interactive interface;

[0028] The interactive interface displays the chart types corresponding to the target data analysis scenario;

[0029] The target chart type selected by the user from the displayed chart types is determined through the interactive interface;

[0030] Data corresponding to the target feature dimensions included in the target data analysis scenario are retrieved from the data warehouse model, a chart of the target chart type is generated, and the chart is displayed on the interactive interface.

[0031] In this embodiment, the user interface allows for easy interaction, enabling users to select the target data analysis scenario and the desired chart type. Based on the user's selection, the system automatically retrieves data from the data warehouse model for analysis and generates and displays charts showing the analysis results. This user-friendly operation significantly lowers the barrier to entry for analyzing battery test data, allowing even users without data analysis experience to obtain results quickly and easily. Furthermore, the analysis process, based on the data warehouse model, provides fast and efficient data querying and support, avoiding system lag and unresponsive charts, thus greatly improving the processing efficiency of battery test data.

[0032] In some embodiments of this application, determining the target data analysis scenario selected by the user through an interactive interface includes:

[0033] The user-submitted first analysis dimension is obtained through the interactive interface, where the first analysis dimension is any one of the feature dimensions.

[0034] Based on the scenario analysis data and the first analysis dimension, determine each second analysis dimension that can be combined with the first analysis dimension to form a data analysis scenario combination;

[0035] The second analysis dimension is displayed in the interactive interface, and the target second analysis dimension selected by the user from the interactive interface is received.

[0036] The data analysis scenario that includes the first analysis dimension and the target second analysis dimension is combined to determine the target data analysis scenario.

[0037] This embodiment guides users through an interactive interface to first select a first analysis dimension, and then select a target second analysis dimension. This step-by-step approach simplifies user operations, lowers the barrier to entry, improves processing efficiency, and enhances the versatility of the battery test data processing method.

[0038] In some embodiments of this application, retrieving data corresponding to the target feature dimensions included in the target data analysis scenario from the data warehouse model includes:

[0039] Based on the data label indications corresponding to the target feature dimensions being continuously distributed over time, the test type to which the target data analysis scenario belongs is determined, and the test type includes normal testing or abnormal testing;

[0040] The data corresponding to the target feature dimension is retrieved from the data warehouse model using the data selection strategy corresponding to the test type.

[0041] Because battery test data from normal and abnormal tests differ somewhat in distribution, normal test data is dense, changes slowly, and has a high signal-to-noise ratio. In contrast, abnormal test data is sparse, exhibits large abrupt changes, and contains many outliers. Therefore, employing different data selection strategies for different test types ensures that data selection is appropriate for the target data analysis scenario, improving the accuracy of the selected data, reducing data redundancy, and ultimately enhancing the accuracy of subsequent analysis based on the selected data.

[0042] In some embodiments of this application, retrieving data corresponding to the target feature dimension from the data warehouse model using a data selection strategy corresponding to the test type includes:

[0043] Based on the fact that the test type is the normal test, the time period corresponding to the data under the target feature dimension in the data warehouse model is divided into multiple sampling windows;

[0044] Based on the data corresponding to the target feature dimension within each sampling window, obtain the statistical indicators corresponding to each sampling window respectively;

[0045] Based on the statistical indicators corresponding to each sampling window, the sampling threshold is determined;

[0046] Based on the sampling threshold and the statistical indicators corresponding to each sampling window, the window category to which each sampling window belongs is determined.

[0047] Based on the window category to which each sampling window belongs, data corresponding to the target feature dimension is retrieved from each sampling window.

[0048] After classifying the sampling windows into different categories using the above method, different data retrieval strategies are employed for each window category. This approach ensures that key data from the target feature dimensions are retrieved while minimizing the amount of data sampled from stable data segments. This approach maintains the accuracy of subsequent data analysis while reducing the amount of data retrieved, thereby reducing memory usage and analysis time in the target data analysis scenario and improving analysis efficiency without compromising accuracy.

[0049] In some embodiments of this application, retrieving data corresponding to the target feature dimension from the data warehouse model using a data selection strategy corresponding to the test type includes:

[0050] Based on the fact that the test type is the normal test, the target data processing template corresponding to the target chart type is obtained from the preset mapping relationship between chart types and data processing templates;

[0051] The target data processing template is used to retrieve the data corresponding to the target feature dimension from the data warehouse model.

[0052] This embodiment categorizes the data selection rules applicable to different chart types, forming a smaller number of target data processing templates. Data selection is performed using the corresponding target data processing template based on the user-selected target chart type, simplifying the operation process, saving system computing resources, and improving processing efficiency.

[0053] In some embodiments of this application, retrieving data corresponding to the target feature dimension from the data warehouse model using a data selection strategy corresponding to the test type includes:

[0054] Based on the fact that the test type is the anomaly test, the time period corresponding to the data under the target feature dimension in the data warehouse model is divided into multiple sampling windows;

[0055] For any two adjacent windows in the plurality of sampling windows, calculate the month-on-month change rate of the target feature data between the two adjacent windows, where the target feature data is the data of the target feature dimension within the corresponding window;

[0056] Based on the year-on-year change rate between each pair of adjacent windows, the abnormal event window is determined from the plurality of sampling windows;

[0057] Retrieve all target feature data from the abnormal event window in the data warehouse model, and retrieve the statistical values ​​of target feature data from the remaining sampling windows other than the abnormal event window.

[0058] This embodiment determines the abnormal event window based on the changes in target feature data between adjacent windows. All data in the abnormal event window are selected, while only statistical values, such as averages and extreme values, are used for target feature data in other windows. This ensures high-fidelity traceability of abnormal segments while reducing the overall amount of selected data, saving resources in data storage, data transmission, and data analysis, and preventing the loss of critical information.

[0059] A second aspect of this application provides a battery test data processing apparatus, comprising:

[0060] The first generation module is used to generate multiple data tables with related relationships based on the battery test data corresponding to the target test items.

[0061] The determination module is used to determine the data label corresponding to each feature dimension based on each feature dimension in the battery test data. The data label is used to characterize the continuity of the corresponding feature dimension.

[0062] The second generation module is used to establish a data warehouse model corresponding to the target test item based on the multiple data tables; and to generate scenario analysis data corresponding to the target test item based on each feature dimension and the data labels corresponding to each feature dimension, wherein the scenario analysis data represents the chart types generated corresponding to different data analysis scenarios.

[0063] A third aspect of this application provides an electronic device including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the method described in the first aspect above.

[0064] A fourth aspect of this application provides a computer-readable storage medium storing a computer program that is executed by a processor to implement the method described in the first aspect above.

[0065] A fifth aspect of this application provides a computer program product, including a computer program that is executed by a processor to implement the method described in the first aspect above.

[0066] The above description is merely an overview of the technical solutions of the embodiments of this application. In order to better understand the technical means of the embodiments of this application and to implement them in accordance with the contents of the specification, and to make the above and other objects, features and advantages of the embodiments of this application more obvious and understandable, specific implementation methods of this application are described below. Attached Figure Description

[0067] Various other advantages and benefits will become apparent to those skilled in the art upon reading the detailed description of the embodiments described below. The accompanying drawings are for illustrative purposes only and are not intended to limit the scope of the application. Furthermore, the same reference numerals denote the same parts throughout the drawings. In the drawings:

[0068] Figure 1 This is a flowchart illustrating a method for processing battery test data according to some embodiments of this application;

[0069] Figure 2 This is another flowchart of a method for processing battery test data according to some embodiments of this application;

[0070] Figure 3 This is a schematic diagram illustrating an example of a data warehouse model storage under cyclic lifetime testing according to some embodiments of this application;

[0071] Figure 4 This is a schematic diagram of a battery test data processing device according to some embodiments of this application;

[0072] Figure 5 This is a schematic diagram of the structure of an electronic device according to some embodiments of this application. Detailed Implementation

[0073] The embodiments of the technical solution of this application will now be described in detail with reference to the accompanying drawings. These embodiments are only used to more clearly illustrate the technical solution of this application and are therefore merely examples, and should not be used to limit the scope of protection of this application.

[0074] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application pertains; the terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the application; the terms “comprising” and “having”, and any variations thereof, in the specification, claims, and foregoing description of the drawings are intended to cover non-exclusive inclusion.

[0075] In the description of the embodiments of this application, technical terms such as "first" and "second" are used only to distinguish different objects and should not be construed as indicating or implying relative importance or implicitly specifying the number, specific order, or primary and secondary relationship of the indicated technical features. In the description of the embodiments of this application, "multiple" means two or more, unless otherwise explicitly defined.

[0076] In this document, the term "embodiment" means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of this application. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

[0077] In the description of the embodiments in this application, the term "and / or" is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent three cases: A exists, A and B exist simultaneously, and B exists. In addition, the character " / " in this document generally indicates that the related objects before and after it have an "or" relationship.

[0078] In the description of the embodiments of this application, the term "multiple" refers to two or more (including two), similarly, "multiple sets" refers to two or more (including two sets), and "multiple pieces" refers to two or more (including two pieces).

[0079] The term "determine" can encompass a wide variety of actions. For example, "determine" can include calculation, operation, processing, deduction, investigation, searching (e.g., searching in a table, database, or other data structure), assertion, etc. Furthermore, "determine" can include receiving (e.g., receiving information), accessing (e.g., accessing data in memory), etc. Additionally, "determine" can include parsing, selecting, picking, building, etc. Those skilled in the art will understand the specific meaning of the above terms in the embodiments of this application according to the specific circumstances.

[0080] Battery devices can include, but are not limited to, individual battery cells, battery modules, battery packs, electrical boxes, electrical cabinets, and energy storage containers. Extensive testing is required during the production and use of battery devices, generating a large amount of battery test data.

[0081] Battery test data involves numerous fields with varying dimensions, making integration difficult for users. Furthermore, the user base requiring analysis of battery test data is broad, ranging from front-end developers unfamiliar with data analysis to seasoned professionals skilled in both. When handling massive amounts of battery test data, traditional data rendering and processing solutions are prone to issues such as slow system response, lag in visualization chart generation, and even service interruptions due to the sheer volume and high load, impacting data analysis efficiency and user experience.

[0082] While there are solutions for processing battery test data in related technologies, most of them focus on the application of data during data acquisition and equipment linkage. There is a lack of solutions for processing, modeling, and multi-dimensional analysis of the battery test data itself.

[0083] Based on the aforementioned problems in related technologies, some embodiments of this application propose a method for processing battery test data. This method generates multiple data tables with interrelationships based on the battery test data corresponding to the target test item; determines data labels corresponding to each feature dimension in the battery test data, with the data labels representing the continuity of the corresponding feature dimensions; establishes a data warehouse model corresponding to the target test item based on the multiple data tables; and generates scenario analysis data corresponding to the target test item based on each feature dimension and the corresponding data labels, where the scenario analysis data represents the chart types generated for different data analysis scenarios.

[0084] This method generates a data table with relationships between battery test data corresponding to the target test items, and then establishes a data warehouse model for the target test items. This effectively improves the processing efficiency of battery test data, and users can easily query the specific data they need from the data warehouse model. Based on this data warehouse model, the query and analysis efficiency of battery test data can be improved. This method determines data labels for the feature dimensions in battery test data, and then generates scenario analysis data. Based on this scenario analysis data, the efficiency of data analysis and chart generation in different data analysis scenarios can be improved. It can transform generalized user self-service analysis in related technologies into efficient and specific scenario analysis, reduce ineffective generalization requirements, significantly reduce battery R&D costs, and reduce the difficulty of analyzing massive amounts of battery test data. Users without data analysis experience can also conveniently and efficiently analyze battery test data with the support of this method.

[0085] In some embodiments of this application, the battery device can be, but is not limited to, a single cell, a battery module, a battery pack, an electrical box, an energy storage cabinet, an energy storage container, etc. The battery device can be, but is not limited to, lithium-ion batteries, lead-acid batteries, nickel-based batteries, sodium-based batteries, etc. Among them, lithium-ion batteries include, but are not limited to, lithium cobalt oxide batteries, lithium manganese oxide batteries, lithium nickel oxide batteries, lithium iron phosphate batteries, etc.

[0086] In some embodiments of this application, the battery device can be of any shape and structure, such as a cylindrical battery, a flat battery, a pouch battery, a prismatic battery, etc. The battery device can be applied to any application scenario requiring battery use. It can be used as a consumer electronics battery, such as in mobile phones and laptops. The battery device can also be used as an energy storage battery, and furthermore, as a power battery, such as in electric vehicles, electric bicycles, electric aircraft, and electric ships.

[0087] The battery test data processing methods provided in some embodiments of this application can be applied to process battery test data in any battery test scenario. For example, they can be used to process battery test data for battery cycle life testing or to process battery test data in a liquid battery leakage test scenario.

[0088] Some embodiments of this application provide a method for processing battery test data; see [link to relevant documentation]. Figure 1 The method specifically includes the following steps:

[0089] Step 101: Based on the battery test data corresponding to the target test item, generate multiple data tables that are related.

[0090] Step 102: Based on each feature dimension in the battery test data, determine the data label corresponding to each feature dimension. The data label is used to characterize the continuity of the corresponding feature dimension.

[0091] Step 103: Establish a data warehouse model corresponding to the target test item based on multiple data tables; and generate scenario analysis data corresponding to the target test item based on each feature dimension and the data labels corresponding to each feature dimension. The scenario analysis data represents the chart types generated corresponding to different data analysis scenarios.

[0092] The executing entity in this application embodiment can be any terminal device, physical server, or cloud server with computing and storage capabilities.

[0093] Test items can refer to the tests required to verify the performance and safety of a battery device. In terms of performance, test items may include, but are not limited to, capacity testing, open-circuit voltage testing, cycle life testing, and self-discharge testing. In terms of safety, test items may include, but are not limited to, overcharge testing, over-discharge testing, short-circuit testing, crush testing, and thermal runaway testing. The aforementioned target test items can be any test item for any aspect of the battery device's performance and safety.

[0094] The battery test data corresponding to the target test item can include all data obtained from testing the battery device under the target test item. In the field of battery testing, in order to improve the accuracy of battery testing and analysis, multiple test orders are usually set under a single battery test item, and multiple test samples are set under a single test order. Each test sample is tested under different test conditions during the testing process. Therefore, a single test item can generate a large amount of battery test data.

[0095] One test order is equivalent to one experimental batch, and the test sample is the battery device being tested. The test conditions may include, but are not limited to, temperature, humidity, charge / discharge rate, etc.

[0096] As an example, assuming the test item is cycle life testing, test sheets A and B can be set up. Test sheet A: using 3 battery packs, cycling 1000 times and pausing to collect mid-term data. Test sheet B: using 3 modules, cycling up to 2000 times and collecting EOL (End of Life) data. Test sheet A includes battery packs 1, 2, and 3; test sheet B includes samples 4, 5, and 6. For the same battery pack, the test conditions will be switched during the test to collect test data under different test conditions.

[0097] For the large amount of battery test data corresponding to the target test items, multiple data tables with interrelationships are generated. These interrelationships refer to two or more data tables establishing logical references through shared fields or keywords, enabling convenient data retrieval between related tables and effectively reducing data redundancy.

[0098] Feature dimensions can refer to independent variable fields in battery test data used to quantitatively describe the battery device or its test conditions. Each feature dimension corresponds to a column or row in the data table, and its values ​​constitute a numerical sequence on that dimension, used to characterize the state, performance, or environmental parameters of the battery device under specific test conditions. As an example, feature dimensions can be, but are not limited to, the cathode material system, test temperature, cycle count, discharge capacity, voltage, etc.

[0099] Data labels are used to characterize the continuity of data under a corresponding feature dimension, that is, to indicate whether the data under the feature dimension appears alone, discretely, or continuously over time. As an example, the feature dimension "positive electrode material system" appears alone; the feature dimension "voltage" changes continuously over time; and the feature dimension "maximum internal discharge pressure" appears discretely.

[0100] The data warehouse model corresponding to the target test item can refer to the multi-layer data structure paradigm corresponding to the target test item. Through layered modeling, heterogeneous data sources are extracted, cleaned, and transformed, and then standardized and organized according to a unified primary key and time dimension. They are stored in the database in star and / or snowflake schemas, thereby supporting high concurrency, low latency online queries and data mining.

[0101] A data analysis scenario can refer to a scenario where data from at least one feature dimension in battery test data is analyzed. This could be a scenario using data from a single feature dimension or a scenario using data from multiple feature dimensions for joint analysis. For different data analysis scenarios, the analysis results, after analyzing the data from the feature dimensions involved in that scenario, can be displayed in the form of charts. Scenario analysis data is used to represent the correspondence between data analysis scenarios and the applicable chart types. These chart types can include, but are not limited to, pie charts, bar charts, histograms, line charts, scatter plots, and line graphs.

[0102] In this embodiment, a data warehouse model is established based on a large amount of battery test data corresponding to the target test items. This reduces redundant data in the battery test data. Subsequently, the data warehouse model can provide efficient and convenient data query services, effectively improving the query and processing efficiency of battery test data. Data tags are used to identify the continuity of feature dimensions. Scenario analysis data is generated based on these feature dimension data tags, which helps improve the efficiency of data analysis and chart generation in different data analysis scenarios. This provides efficient, specific scenario analysis, reduces ineffective generalization requirements, lowers battery R&D costs and battery test data analysis costs, and reduces the difficulty of analyzing massive amounts of battery test data. This allows users lacking data analysis experience to conveniently and efficiently analyze battery test data.

[0103] In some embodiments of this application, multiple data tables with an association relationship can be generated in the following manner: data cleaning of battery test data corresponding to the target test item; generating multiple data tables based on the table granularity information corresponding to the target test item and the cleaned battery test data, wherein the table granularity information is used to record the preset granularity of different data tables corresponding to the target test item; storing the same association key in at least two of the multiple data tables, wherein the association key is used to make at least two data tables have an association relationship.

[0104] The data cleaning described above is a preprocessing step performed on the battery test data corresponding to the target test item. This includes, but is not limited to, integrity verification, time series continuity restoration, physical boundary filtering, deduplication, and unit and dimension unification. Integrity verification checks for missing essential dimensions in the battery test data. Essential dimensions refer to the feature dimensions necessary for the test analysis of the target test item, such as sample code, cycle number, current, voltage, capacity, and temperature. If any essential dimension is found to be completely missing or contains missing data, the row or column corresponding to that feature dimension is marked as a missing record, and the missing record is deleted from the battery test data.

[0105] The aforementioned time series continuity restoration can be used to repair missing data in a feature dimension that is continuous in time. As an example, missing data can be filled in using linear interpolation. The aforementioned physical boundary filtering can be used to delete outliers in battery test data that exceed a preset threshold range. The aforementioned deduplication refers to retaining only one copy of duplicate data in battery test data and deleting the other duplicates. The aforementioned unit and dimension unification is used to unify the units of the same physical quantities that are inconsistent in unit; for example, some current units are A, and some current units are mA, so they can be unified to A.

[0106] In the embodiments of this application, the system can pre-store table information corresponding to the target test item. This table information can be pre-configured with identifier information of the data table to be generated for the target test item, as well as table granularity information. The identifier information of the data table can be the name or number of the data table. The table granularity information is used to specify the metadata recorded in a row of the data table, clarifying the content represented by that row. As an example, the table granularity information can specify that a row in the data table represents 1 second of real-time sampling data of a battery device during a charging step in a certain cycle; or, the table granularity information can specify that a row in the data table represents the summary data of a battery device during a certain cycle.

[0107] Taking the first data table as an example, the data table generation process is illustrated. The first data table is any one of the multiple data tables required for this target test item. Specifically, the data required for the first data table is obtained from the cleaned battery test data. Based on the pre-configured table granularity information corresponding to the first data table, the data required for the first data table is integrated into multiple records (multiple rows or multiple columns of data). These multiple records are then written into the table to obtain the first data table. Other data tables are generated in the same way.

[0108] After generating multiple data tables corresponding to the target test items in the above manner, store the same association key in at least two data tables. The role of the association key is to link multiple data tables that store the association key together, so that data can be easily queried between the related data tables.

[0109] As an example, Tables 1-3 are relational data tables. Table 1 stores the mapping between cathode material systems and sample codes, Table 2 stores the mapping between sample codes and test IDs, and Table 3 stores the mapping between test IDs and specific test data. If you need to query the test data of a sample battery using a specific cathode material system, you can query the sample codes of battery samples using that cathode material system from Table 1. Based on the retrieved sample codes, you can retrieve all the corresponding test IDs for these battery samples from Table 2. Then, based on each retrieved test ID, you can obtain the corresponding specific test data from Table 3. Thus, for large datasets of specific test data, only one copy needs to be stored.

[0110] In the above embodiments, data cleaning effectively reduces abnormal and duplicate data in battery test data, thereby reducing the storage space occupied by the battery test data. The cleaned battery test data is more standardized, which helps improve the accuracy of subsequent analysis and processing based on it. Generating multiple related data tables based on the cleaned battery test data effectively reduces data redundancy and the storage space occupied by the battery test data corresponding to the target test items. Furthermore, the multiple related data tables provide more efficient data query services.

[0111] In some embodiments of this application, the multiple data tables with correlations under the target test item include a fact table and a dimension table. The fact table records detailed metrics of quantifiable battery behavior events. Each row corresponds to a specific test event or sampling point and includes a foreign key column and a numerical metric column related to the event. The foreign key column points to the primary key of the dimension table. The numerical metric column includes at least one or more of the following: capacity, energy, voltage, current, temperature, internal resistance, and cycle count. The foreign key and primary key are the correlation keys described above, and the fact table and dimension table with a pointing relationship between the foreign key and the primary key are the data tables with correlations.

[0112] A dimension table is a reference table used to describe the static or slowly changing attributes associated with a fact table. Its primary key exists as a foreign key in the fact table. Dimension columns include at least one or more of the following: sample code, test item identifier, test equipment identifier, test step identifier, time identifier, operating condition identifier, and project identifier, to provide the contextual information needed to slice, aggregate, filter, and trace the measures in the fact table.

[0113] For multiple data tables representing the target test item, a star schema can be used for logical modeling of the dimension tables whose attributes do not change over time and their associated fact tables. This results in a data model with the fact table at the center, and the associated dimension tables connected around it, forming a near-star shape. Conversely, for the dimension tables whose attributes change over time and their corresponding fact tables, a snowflake schema can be used for logical modeling. This involves centering on a fact table, connecting the associated dimension tables around it, and then connecting the dimension tables to other fact tables, and so on, resulting in a near-snowflake shape. These star and snowflake schemas, established in this way, constitute the hybrid data warehouse model corresponding to the target test item. This data warehouse model can then be used to provide users with efficient data query services.

[0114] In some embodiments of this application, data labels corresponding to each feature dimension are determined based on each feature dimension in the battery test data, including: obtaining each feature data under a first feature dimension from the battery test data; the first feature dimension is any dimension among the feature dimensions included in the battery test data; determining the distribution pattern of each feature data under the first feature dimension over time; and assigning data labels to the first feature dimension based on the distribution pattern of each feature data over time.

[0115] The feature dimensions in battery test data can be obtained by classifying the feature data in the battery test data and reflected in the data table. The feature dimension can represent a row or column of data in the data table that belongs to the same category. For example, if a row in the data table consists of current values, then the feature dimension corresponding to that row is current.

[0116] We extract feature data from the battery test data under the first feature dimension and analyze the distribution pattern of each feature data over time. The distribution pattern can be either time-independent or time-dependent. The time-dependent pattern can be further divided into continuous distribution over time or discrete occurrence within the test period.

[0117] As an example, the cathode material system is time-independent, while the current is time-dependent and continuously distributed over time. The maximum voltage is time-dependent and occurs discretely within the test period.

[0118] Based on the temporal distribution pattern of each feature data in the first feature dimension, corresponding data labels are assigned to the first feature dimension. In some embodiments, different strings can be used to identify different data labels. As an example, a data label value of 00 indicates that it is unrelated to time, a value of 01 indicates that it is related to time, a value of 10 indicates that it is continuously distributed over time, and a value of 11 indicates that it appears discretely within the test period. In other embodiments, different data labels can also be identified using text, such as a data label value of "no" indicating that it is unrelated to time, a value of "yes" indicating that it is related to time, a value of "continuous curve" indicating that it is continuously distributed over time, and a value of "continuous index" indicating that it appears discretely within the test period.

[0119] This embodiment determines the temporal distribution pattern of each feature data point within a feature dimension, and assigns data labels to the feature dimensions accordingly. This allows for the rapid determination of the temporal distribution pattern of data within a feature dimension based on its data labels. This facilitates subsequent determination of the effectiveness of different feature dimension combinations and the appropriate chart types for different feature dimension combinations, thereby providing users with scenario-specific processing services for various data analysis scenarios, improving the efficiency of battery test data processing, and reducing the difficulty of battery test data processing.

[0120] In some embodiments of this application, scene analysis data corresponding to the target test item is generated based on each feature dimension and the data labels corresponding to each feature dimension, including:

[0121] Based on each feature dimension and its corresponding data label, the feature dimensions are arranged and combined to obtain various data analysis scenario combinations. Each data analysis scenario combination includes at least one feature dimension and its corresponding data label. From these combinations, the target data analysis scenario combinations that can display the analysis results in chart form are selected. The chart type applicable to each target data analysis scenario combination is determined. Based on each target data analysis scenario combination and its corresponding chart type, scenario analysis data is generated.

[0122] The data analysis scenario combinations described above can include only one feature dimension; this type of data analysis scenario combination can be called a single-indicator analysis scenario. Data analysis scenario combinations can also include multiple feature dimensions; this type of data analysis scenario can be called a multi-indicator analysis scenario. As an example, a data analysis scenario combination can include two feature dimensions, which is called a dual-indicator analysis scenario.

[0123] A target data analysis scenario combination refers to a data analysis scenario that can use chart formats such as pie charts, histograms, line charts, and curve charts to display the analysis results. A target data analysis scenario combination may only use one type of chart to display the analysis results, or it may use multiple types of charts to display the analysis results.

[0124] For single-indicator analysis scenarios, applicable chart types include, but are not limited to, pie charts, histograms, and bar charts. For dual-indicator analysis scenarios, applicable chart types include, but are not limited to, line charts, curve charts, scatter plots, bar charts, column charts, box plots, and bubble charts. For data analysis scenarios with more than two feature dimensions, since the analysis results cannot be represented using planar graphics, these scenarios are not considered as target data analysis scenarios. However, the possibility of using three-dimensional graphs to represent the analysis results is not excluded.

[0125] For each target data analysis scenario combination, after determining the corresponding chart type, the mapping relationship between each target data analysis scenario combination and the corresponding chart type is stored, and this mapping relationship is used as the scenario analysis data.

[0126] This embodiment, based on feature dimensions and their corresponding data labels, filters out target data analysis scenario combinations that can display analysis results graphically, and determines the appropriate chart types for each target data analysis scenario component. This provides a richer set of data analysis scenarios, offering data analysis services to users on a scenario-by-scenario basis, reducing ineffective generalization requests, and significantly improving the convenience of data analysis and lowering the barrier to entry for users. Furthermore, by analyzing data through scenarios, the appropriate chart types for different target data analysis scenarios can be clearly identified. When providing scenario analysis services, it is easy to use suitable visualization charts to display analysis results, improving the efficiency of battery test data analysis and the effectiveness of result presentation.

[0127] In some embodiments of this application, the target data analysis scenario selected by the user can also be determined through an interactive interface; the chart type corresponding to the target data analysis scenario can be displayed in the interactive interface; the target chart type selected by the user from the displayed chart types can be determined through the interactive interface; the data corresponding to the target feature dimensions included in the target data analysis scenario can be retrieved from the data warehouse model, a chart of the target chart type can be generated, and the chart can be displayed in the interactive interface.

[0128] In some embodiments, multiple candidate target data analysis scenarios can be displayed in the interactive interface. Users can browse the feature dimensions included in these target data analysis scenarios through the interactive interface. If they need to analyze the feature dimensions included in a certain target data analysis scenario, they can select that target data analysis scenario. When the system detects that the target data analysis scenario has been selected, it will set that target data analysis scenario as the user's selected target data analysis scenario, and then display the various chart types applicable to that target data analysis scenario in the interactive interface.

[0129] Users can select the chart type they need from the displayed chart types. After the system detects the chart type selected by the user, it retrieves the data under each feature dimension of the target data analysis scenario from the data warehouse model corresponding to the target test item, analyzes the retrieved data, generates a chart of the chart type selected by the user, and displays the chart in the interactive interface.

[0130] In this embodiment, the user interface allows for easy interaction, enabling users to select the target data analysis scenario and the desired chart type. Based on the user's selection, the system automatically retrieves data from the data warehouse model for analysis and generates and displays charts showing the analysis results. This user-friendly operation significantly lowers the barrier to entry for analyzing battery test data, allowing even users without data analysis experience to obtain results quickly and easily. Furthermore, the analysis process, based on the data warehouse model, provides fast and efficient data querying and support, avoiding system lag and unresponsive charts, thus greatly improving the processing efficiency of battery test data.

[0131] In some other embodiments of this application, determining the target data analysis scenario selected by the user through an interactive interface includes: obtaining a first analysis dimension submitted by the user through the interactive interface, wherein the first analysis dimension is any dimension among the feature dimensions; determining each second analysis dimension that can be combined with the first analysis dimension to form a data analysis scenario combination based on the scenario analysis data and the first analysis dimension; displaying the second analysis dimensions in the interactive interface and receiving the target second analysis dimension selected by the user from the interactive interface; and combining the data analysis scenarios containing the first analysis dimension and the target second analysis dimension to determine the target data analysis scenario.

[0132] In some embodiments, a client for processing battery test data can be provided to the user. After logging into the client, the homepage can display multiple test items. The user selects one test item and can then configure data filtering settings for that selected test item, such as filtering individual test orders or battery samples under that test item. Based on the user's settings for the test item, the client determines the filtered dataset, which includes the battery test data of the test orders or battery samples set by the user. The client can display a preview page of the dataset, which may include an overview and detailed sections for user viewing. The preview page can also provide a download interface for the dataset, allowing users to directly download it.

[0133] Building upon the aforementioned user interaction and processing, multiple selectable feature dimensions can be displayed on the page. Users can choose one feature dimension from these options for their analysis; this feature dimension is the first analysis dimension mentioned above. After obtaining the first analysis dimension, the system queries multiple data analysis scenario combinations included in the scenario analysis data and selects the data analysis scenario combination that contains the first analysis dimension. The interactive interface then displays the other feature dimensions from these data analysis scenario combinations besides the first analysis dimension; these other feature dimensions are the second analysis dimension mentioned above.

[0134] Users can select one of the various second analysis dimensions displayed on the interactive interface. After the system detects the target second analysis dimension selected by the user, it determines the data analysis scenario that includes the first analysis dimension and the target second analysis dimension as the target data analysis scenario.

[0135] This embodiment guides users through an interactive interface to first select a first analysis dimension, and then select a target second analysis dimension. This step-by-step approach simplifies user operations, lowers the barrier to entry, improves processing efficiency, and enhances the versatility of the battery test data processing method.

[0136] In some embodiments of this application, after determining the target data analysis scenario and corresponding chart type selected by the user, it is necessary to first retrieve the data corresponding to the target feature dimensions included in the target data analysis scenario from the data warehouse model. The specific retrieval process includes: determining the test type to which the target data analysis scenario belongs based on the data label indication that the target feature dimensions are continuously distributed in time, and the test type includes normal test or abnormal test; and retrieving the data corresponding to the target feature dimensions from the data warehouse model using the data selection strategy corresponding to the test type.

[0137] The aforementioned routine tests are standard tests performed on the performance and safety of the battery device, and do not involve testing for abnormal or malfunctioning conditions. For example, routine tests may include cycle life testing, capacity testing, and open-circuit voltage testing. Abnormal tests, on the other hand, test for abnormal or malfunctioning conditions of the battery device. For example, abnormal tests may include leakage testing, fire testing, and crush testing.

[0138] When the data labels of the target feature dimension indicate that the data of the target feature dimension is continuously distributed over time, the test type of the target data analysis scenario can be determined as normal testing or abnormal testing based on whether there are preset abnormal fields in the project information of the target test item. These preset abnormal fields can include keywords related to abnormalities or malfunctions, such as leakage, fire, and compression.

[0139] In other embodiments, the test conditions corresponding to the data of the target feature dimension can also be obtained, and it can be determined whether each parameter in the test conditions (such as temperature, voltage, current, mechanical stress, etc.) exceeds the corresponding parameter range given in the battery device's specifications. If any parameter in the test conditions exceeds the corresponding parameter range, the test type of the target data analysis scenario is determined to be an abnormal test. If all parameters in the test conditions do not exceed the corresponding parameter range, the test type is determined to be a normal test.

[0140] The data selection strategy corresponding to the above test types is a set of rules, which includes, but is not limited to, boundary rules and density rules. Boundary rules are used to determine whether the data falls within a valid physical interval. Density rules are used to determine the sampling frequency or window length to suppress redundancy or noise.

[0141] Because battery test data from normal and abnormal tests differ somewhat in distribution, normal test data is dense, changes slowly, and has a high signal-to-noise ratio. In contrast, abnormal test data is sparse, exhibits large abrupt changes, and contains many outliers. Therefore, employing different data selection strategies for different test types ensures that data selection is appropriate for the target data analysis scenario, improving the accuracy of the selected data, reducing data redundancy, and ultimately enhancing the accuracy of subsequent analysis based on the selected data.

[0142] In some embodiments of this application, when the test type of the target data analysis scenario is a normal test, the data is retrieved in the following manner: the time period corresponding to the data under the target feature dimension in the data warehouse model is divided into multiple sampling windows; based on the data corresponding to the target feature dimension in each sampling window, the statistical indicators corresponding to each sampling window are obtained respectively; based on the statistical indicators corresponding to each sampling window, the sampling threshold is determined; based on the sampling threshold and the statistical indicators corresponding to each sampling window, the window category to which each sampling window belongs is determined respectively; based on the window category to which each sampling window belongs, the data corresponding to the target feature dimension is retrieved from each sampling window respectively.

[0143] The sampling window is the smallest data segment that satisfies time closure and data closure, which is truncated from the data of the target feature dimension by a fixed duration Δt and a sliding step size δ. Δt and δ can be preset.

[0144] The statistical indicators corresponding to the sampling window can be obtained by statistically calculating the data within the sampling window. These indicators include, but are not limited to, the range and rate of change of the data within the sampling window. The range refers to the difference between the maximum and minimum values ​​of the target feature dimension within the sampling window. The rate of change can refer to the difference between the last and first values ​​of the target feature dimension within the sampling window. For each sampling window, the statistical indicators for each sampling window are obtained separately.

[0145] The aforementioned sampling thresholds are boundary values ​​used to filter data from the data warehouse model for target feature dimensions. Specifically, the ranges of each sampling window can be arranged in chronological order according to the time corresponding to each sampling window to obtain a range sequence. The median range value is selected from this range sequence, and the median range value that is a first preset multiple is used as the first threshold included in the sampling threshold.

[0146] Alternatively, the changes in each sampling window can be arranged in chronological order according to the time corresponding to each sampling window to obtain a change sequence. The difference between the last change and the first change in this change sequence is calculated, and this difference, which is a second preset multiple, is used as the second threshold included in the sampling threshold. In other embodiments, the difference between the last value and the first value in the target feature dimension data can also be directly calculated, and this difference, which is a second preset multiple, is used as the second threshold included in the sampling threshold.

[0147] The window categories described above are used to distinguish sampling windows with different sampling densities. Sampling density refers to the density of data selected from the sampling window; the higher the sampling density, the more data is selected from the sampling window. Specifically, the window category to which the sampling window belongs can be determined based on the relationship between the range of the data within the sampling window and the aforementioned sampling threshold.

[0148] Specifically, if the range of data within the sampling window is greater than the first threshold and the change is greater than the second threshold, then the sampling window is classified as the first window category. The first window category is the key feature window, which has the highest data acquisition density among all window categories. All original data points within the sampling window need to be retained to ensure high fidelity. If the range of data within the sampling window is greater than the first threshold and the change is less than or equal to the second threshold, then the sampling window is classified as the second window category. The data acquisition density of the second window category is lower than that of the first window category. An interval sampling mode is used within the sampling window of the second window category to reduce the data acquisition density of that sampling window.

[0149] If the change in data within the sampling window exceeds the second threshold, and the range is less than or equal to the first threshold, then the sampling window is classified as a third window category. The data acquisition density of the third window category is lower than that of the second window category. The sampling window of the third window category uses a feature point sampling mode to capture key feature points within that window. Specifically, this can be achieved by sampling data within the time period during which the slope of the curve formed by the target feature dimension data changes within the sampling window of the third window category.

[0150] If the range of data within the sampling window is less than or equal to the first threshold and the change is less than or equal to the second threshold, then the sampling window is determined to be the fourth window category. The data collection density of the fourth window category is less than that of the third window category. The sampling window of the fourth window category is a stationary data window, and only the statistical characteristic values ​​of the sampling window (such as the mean, extreme values, etc. of the data of the target feature dimension within the sampling window) are retained, which greatly compresses the amount of data.

[0151] After classifying the sampling windows into different categories using the above method, different data retrieval strategies are employed for each window category. This approach ensures that key data from the target feature dimensions are retrieved while minimizing the amount of data sampled from stable data segments. This approach maintains the accuracy of subsequent data analysis while reducing the amount of data retrieved, thereby reducing memory usage and analysis time in the target data analysis scenario and improving analysis efficiency without compromising accuracy.

[0152] Different chart types may share certain commonalities in data selection. For example, in a phase where the slope remains unchanged, the data is relatively stable with little variation, and fewer data samples can be taken in this phase. Conversely, in a phase where the slope changes, the data shows a sudden change, requiring more data samples. Based on this, in some embodiments of this application, various chart types can be categorized and different data processing templates can be generated based on user requirements for the chart types used to display analysis results. A data processing template can be a set of rules for selecting data for at least one corresponding chart type. These data processing templates can be pre-generated, and a mapping relationship between chart types and data processing templates can be pre-configured in the system. In this mapping relationship, one data processing template can correspond to one or more chart types.

[0153] As an example, in cyclic life testing, the above rules can be predefined based on different decay curve templates (such as slow decay and rapid decay) to automatically execute the sampling strategy. Here, "the above rules" can include the rules mentioned earlier for selecting data using different sampling densities based on different window categories, which will not be elaborated upon here.

[0154] Specifically, when the test type for the target data analysis scenario is a normal test, data can be selected in the following way: obtain the target data processing template corresponding to the target chart type from the preset mapping relationship between chart types and data processing templates; and retrieve the data corresponding to the target feature dimension from the data warehouse model through the target data processing template.

[0155] Under normal testing conditions, the target data processing template corresponding to the user's selected target chart type is obtained from the above mapping relationship. Data for the target feature dimension is then scheduled from the data warehouse model using the data selection rules in this target data processing template.

[0156] This embodiment categorizes the data selection rules applicable to different chart types, forming a smaller number of target data processing templates. Data selection is performed using the corresponding target data processing template based on the user-selected target chart type, simplifying the operation process, saving system computing resources, and improving processing efficiency.

[0157] In other embodiments of this application, when the test type of the target data analysis scenario is an anomaly type, the data is retrieved in the following ways:

[0158] The time period corresponding to the data under the target feature dimension in the data warehouse model is divided into multiple sampling windows. For any two adjacent windows in the multiple sampling windows, the month-on-month change rate of the target feature data between the two adjacent windows is calculated. The target feature data is data that is continuously distributed in time. Based on the month-on-month change rate between each pair of adjacent windows, the abnormal event window is determined from the multiple sampling windows. All target feature data in the abnormal event window are retrieved from the data warehouse model, as well as the statistical values ​​of the target feature data in the remaining sampling windows excluding the abnormal event window.

[0159] The meaning and division method of the sampling window are the same as those described above, and will not be repeated here.

[0160] The aforementioned month-on-month change rate = (mean of current window indicators - mean of previous window indicators) ÷ mean of previous window indicators × 100%. The indicator mean is the average value of the data of the target feature dimension (i.e., the target feature data mentioned above) within the sampling window.

[0161] The aforementioned abnormal event window refers to a sampling window that begins when the month-on-month change rate first exceeds or equals a preset safety threshold, and then continues to fall back below the preset safety threshold for a certain period of time. The abnormal event window is used to fully capture abnormal transients and the decay process.

[0162] Specifically, starting from the moment when the month-on-month change rate first exceeds or equals the preset safety threshold, the sampling window can be continuously slid backward until the month-on-month change rate is continuously less than the preset safety threshold and maintains a data interval of no less than N windows (or no less than T seconds). The aforementioned abnormal event window includes each sampling window within this entire data interval.

[0163] This embodiment determines the abnormal event window based on the changes in target feature data between adjacent windows. All data in the abnormal event window are selected, while only statistical values, such as averages and extreme values, are used for target feature data in other windows. This ensures high-fidelity traceability of abnormal segments while reducing the overall amount of selected data, saving resources in data storage, data transmission, and data analysis, and preventing the loss of critical information.

[0164] In some embodiments of this application, such as Figure 2 As shown, before analyzing and processing the target data scenario, it's possible to first determine whether the total amount of target feature data for each target feature dimension exceeds a threshold. If it's less than or equal to the threshold, all target feature data for each target feature dimension can be directly obtained, data processing can be performed directly, and a chart of the user-selected target chart type can be generated. This allows for direct processing even when the data volume is less than the threshold, preventing system lag due to the small data size.

[0165] If the data volume exceeds the threshold, the test type of the target data analysis scenario can be determined according to the previous embodiment. If the test type is an anomaly test, active sampling is used to select data. Active sampling refers to sampling all target feature data in the anomaly event window and sampling only the statistical values ​​of target feature data in other windows, as described above. If the test type is a normal test, mutation point capture is used for sampling. The mutation point capture method is based on the relationship between the range and the first threshold, and the relationship between the change and the second threshold, as described above, to determine the window category of each sampling window. Different sampling densities are used for sampling windows of different categories.

[0166] The description of the various embodiments above tends to emphasize the differences between the various embodiments. The similarities or similarities between them can be referred to, and for the sake of brevity, they will not be repeated here.

[0167] To facilitate understanding of the battery test data processing process provided in the embodiments of this application, the following example illustrates the process of processing test data for testing a battery pack.

[0168] Step 1: Obtain the variable parameters of the target test item (i.e., battery test data).

[0169] Step 2: Classify the variable parameters of the target test items according to the acquisition logic, data type, and analysis dimension, and establish a hybrid data model storage specification, such as establishing a data warehouse model that combines star and snowflake schemas.

[0170] As an example, a cycle life test was conducted on a battery pack, and the data types and analysis dimensions of the test data were categorized. Table 1 shows some of the categorization results. In Table 1, the data label "Yes" indicates that the corresponding analysis indicator is related to time, the data label "No" indicates that the corresponding analysis indicator is not related to time, the data label "Continuous indicator" indicates that the corresponding analysis indicator is discretely distributed over time, and the data label "Continuous curve" indicates that the corresponding analysis indicator is continuously distributed over time. Figure 3 A schematic diagram of a data warehouse model storage example under cyclic lifetime testing is shown.

[0171] Table 1

[0172]

[0173] Step 3: Based on the data split in Step 2, perform continuous analysis to determine the analysis scenario and corresponding charts.

[0174] Table 2 shows the correspondence between analysis scenarios and chart types under single-indicator analysis. Table 3 shows the correspondence between analysis scenarios and chart types under dual-indicator analysis.

[0175] Table 2

[0176]

[0177] Table 3

[0178]

[0179] Step 4: Based on the data warehouse model and data classification established in Step 1 and Step 2, establish the data processing and analysis functional logic.

[0180] The homepage uses an interactive interface to determine the user's selected test items and allows for initial data screening. Based on the user-selected data, a first dataset is created. The interactive interface displays an overview and detailed data for this first dataset, and provides a download interface for users to directly download the data.

[0181] Based on this, the user-selected x-axis data is determined through the interactive interface. According to the feasible analysis dimensions determined in steps two and three, a list of selectable y-axis data types is displayed in the interactive interface. After the user selects the y-axis data type, the corresponding chart types for the x-axis and y-axis data are displayed through the interactive interface, based on the applicable charts from step three. The user then selects the appropriate chart type. The x-axis and y-axis data are retrieved from the data warehouse model, and a chart of the user-specified chart type is generated based on the retrieved data.

[0182] The first set of datasets can also be filtered and modified through the corresponding indicator fields (such as test order, sample code, etc.) on the interactive interface, thereby analyzing test data of different batteries.

[0183] The description of the various embodiments above tends to emphasize the differences between the various embodiments. The similarities or similarities between them can be referred to, and for the sake of brevity, they will not be repeated here.

[0184] Some embodiments of this application also provide a battery test data processing apparatus, which is used to execute a battery test data processing method provided in any of the above embodiments, such as... Figure 4 As shown, the device includes:

[0185] The first generation module 201 is used to generate multiple data tables with related relationships based on the battery test data corresponding to the target test item.

[0186] The determination module 202 is used to determine the data label corresponding to each feature dimension based on each feature dimension in the battery test data. The data label is used to characterize the continuity of the corresponding feature dimension.

[0187] The second generation module 203 is used to establish a data warehouse model corresponding to the target test item based on multiple data tables; and to generate scenario analysis data corresponding to the target test item based on each feature dimension and the data labels corresponding to each feature dimension. The scenario analysis data represents the chart types generated corresponding to different data analysis scenarios.

[0188] The first generation module 201 is used to clean the battery test data corresponding to the target test item; based on the table granularity information corresponding to the target test item and the cleaned battery test data, it generates multiple data tables, the table granularity information is used to record the preset granularity of different data tables corresponding to the target test item; the same association key is stored in at least two of the multiple data tables, the association key is used to make at least two data tables have an association relationship.

[0189] The determination module 202 is used to obtain feature data under the first feature dimension from the battery test data; the first feature dimension is any dimension among the feature dimensions; determine the distribution pattern of each feature data under the first feature dimension over time; and assign data labels to the first feature dimension based on the distribution pattern of each feature data over time.

[0190] The second generation module 203 is used to arrange and combine each feature dimension based on each feature dimension and the data label corresponding to each feature dimension to obtain multiple data analysis scenario combinations; the data analysis scenario combination includes at least one feature dimension and at least one data label corresponding to the feature dimension; from the multiple data analysis scenario combinations, select each target data analysis scenario combination that can display the analysis results in the form of charts;

[0191] Determine the appropriate chart types for each target data analysis scenario combination; generate scenario analysis data based on each target data analysis scenario combination and the corresponding chart types.

[0192] The device also includes: an interactive analysis module, used to determine the target data analysis scenario selected by the user through an interactive interface; display the chart type corresponding to the target data analysis scenario in the interactive interface; determine the target chart type selected by the user from the displayed chart types through the interactive interface; retrieve the data corresponding to the target feature dimensions included in the target data analysis scenario from the data warehouse model, generate a chart of the target chart type, and display the chart in the interactive interface.

[0193] The interactive analysis module is used to obtain the first analysis dimension submitted by the user through an interactive interface. The first analysis dimension is any dimension among the feature dimensions. Based on the scenario analysis data and the first analysis dimension, it determines each second analysis dimension that can be combined with the first analysis dimension to form a data analysis scenario combination. It displays the second analysis dimensions in the interactive interface and receives the target second analysis dimension selected by the user from the interactive interface. It combines the data analysis scenarios containing the first analysis dimension and the target second analysis dimension to determine the target data analysis scenario.

[0194] The interactive analysis module is used to determine the test type of the target data analysis scenario based on the data label indication that the target feature dimension is continuously distributed over time. The test type includes normal test or abnormal test. The module then uses the data selection strategy corresponding to the test type to retrieve the data corresponding to the target feature dimension from the data warehouse model.

[0195] The interactive analysis module is used to divide the time period corresponding to the data under the target feature dimension in the data warehouse model into multiple sampling windows based on the test type being normal testing; based on the data corresponding to the target feature dimension within each sampling window, it obtains the statistical indicators corresponding to each sampling window; based on the statistical indicators corresponding to each sampling window, it determines the sampling threshold; based on the sampling threshold and the statistical indicators corresponding to each sampling window, it determines the window category to which each sampling window belongs; based on the window category to which each sampling window belongs, it retrieves the data corresponding to the target feature dimension from each sampling window.

[0196] The interactive analysis module is used for routine testing. It retrieves the target data processing template corresponding to the target chart type from the preset mapping relationship between chart types and data processing templates. Then, it retrieves the data corresponding to the target feature dimension from the data warehouse model using the target data processing template.

[0197] The interactive analysis module is used to divide the time period corresponding to the data under the target feature dimension in the data warehouse model into multiple sampling windows based on the test type of anomaly testing. For any two adjacent windows in the multiple sampling windows, the month-on-month change rate of the target feature data between the two adjacent windows is calculated. The target feature data is the data of the target feature dimension within the corresponding window. Based on the month-on-month change rate between each pair of adjacent windows, the anomaly event window is determined from the multiple sampling windows. All target feature data in the anomaly event window are retrieved from the data warehouse model, as well as the statistical values ​​of the target feature data in the remaining sampling windows excluding the anomaly event window.

[0198] The description of the various embodiments above tends to emphasize the differences between the various embodiments. The similarities or similarities between them can be referred to, and for the sake of brevity, they will not be repeated here.

[0199] Other embodiments of this application provide an electronic device including a memory, a processor, and a computer program stored in the memory and executable on the processor. The processor executes the computer program to implement the battery test data processing method of any of the above embodiments.

[0200] like Figure 5 As shown, the electronic device 60 may include: a processor 600, a memory 601, a bus 602 and a communication interface 603. The processor 600, the communication interface 603 and the memory 601 are connected through the bus 602. The memory 601 stores a computer program that can run on the processor 600. When the processor 600 runs the computer program, it executes the method provided in any of the foregoing embodiments of this application.

[0201] The memory 601 may include high-speed random access memory (RAM), and may also include non-volatile memory, such as at least one disk storage device. Communication between the device network element and at least one other network element is achieved through at least one communication interface 603 (which may be wired or wireless), such as the Internet, wide area network, local area network, metropolitan area network, etc.

[0202] Bus 602 can be an ISA bus, PCI bus, or EISA bus, etc. Buses can be divided into address buses, data buses, control buses, etc. Memory 601 stores computer programs. After receiving execution instructions, processor 600 executes the computer program. The methods disclosed in any of the foregoing embodiments of this application can be applied to processor 600, or implemented by processor 600.

[0203] The processor 600 may be an integrated circuit chip with signal processing capabilities. In implementation, each step of the above method can be completed by the integrated logic circuitry in the hardware of the processor 600 or by instructions in software form. The processor 600 can be a general-purpose processor, including a Central Processing Unit (CPU), a Network Processor (NP), etc.; it can also be a Digital Signal Processor (DSP), an Application-Specific Integrated Circuit (ASIC), an Off-the-shelf Programmable Gate Array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this application can be directly embodied in the execution of a hardware decoding processor, or executed by a combination of hardware and software modules in the decoding processor. The software modules can be located in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. The storage medium is located in memory 601. Processor 600 reads the information in memory 601 and, in conjunction with its hardware, completes the steps of the above method.

[0204] The electronic devices and methods provided in the embodiments of this application are based on the same inventive concept and have the same beneficial effects as the methods they employ, operate, or implement.

[0205] Other embodiments of this application provide a computer-readable storage medium having a computer program stored thereon, which is executed by a processor to implement the methods of any of the above embodiments.

[0206] The computer-readable storage medium provided in the embodiments of this application and the method provided in the embodiments of this application are based on the same inventive concept and have the same beneficial effects as the methods used, operated or implemented therein.

[0207] This application also provides a computer program product corresponding to the method provided in the foregoing embodiments. The computer program product includes a computer program that is executed by a processor to implement the method provided in the foregoing embodiments.

[0208] The computer program products provided in the above embodiments of this application and the methods provided in the embodiments of this application are based on the same inventive concept and have the same beneficial effects as the methods adopted, run or implemented by the application models stored therein.

[0209] The description of the various embodiments above tends to emphasize the differences between the various embodiments. The similarities or similarities between them can be referred to, and for the sake of brevity, they will not be repeated here.

[0210] It should be noted that:

[0211] The term "module" is not intended to be limited to a specific physical form. Depending on the application, a module can be implemented as hardware, firmware, software, and / or a combination thereof. Furthermore, different modules may share common components or even be implemented using the same components. Clear boundaries may or may not exist between different modules.

[0212] The algorithms and displays provided herein are not inherently related to any particular computer, virtual device, or other equipment. Various general-purpose devices can also be used with the examples based on this. The required structure for constructing such devices is obvious from the above description. Furthermore, this application is not directed to any particular programming language. It should be understood that the content of this application described herein can be implemented using various programming languages, and the above description of specific languages ​​is for the purpose of disclosing the best mode of implementation of this application.

[0213] It should be understood that although the steps in the flowcharts of the accompanying figures are shown sequentially as indicated by the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the accompanying figures may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times, and their execution order is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the sub-steps or stages of other steps.

[0214] The above embodiments merely illustrate the implementation methods of this application, and while the descriptions are relatively specific and detailed, they should not be construed as limiting the scope of this application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A method for processing battery test data, characterized in that, include: Based on the battery test data corresponding to the target test items, generate multiple data tables that are related to each other; Based on the temporal distribution patterns of feature data under each feature dimension in the battery test data, corresponding data labels are assigned to each feature dimension. The data labels are used to characterize the continuity of the corresponding feature dimension. The temporal distribution patterns include time-independent and time-dependent patterns. The time-dependent patterns include continuous temporal distribution and discrete occurrence within the test period. A data warehouse model corresponding to the target test item is established based on the multiple data tables; and, based on each feature dimension and the data labels corresponding to each feature dimension, scenario analysis data corresponding to the target test item is generated, wherein the scenario analysis data represents the chart types generated corresponding to different data analysis scenarios; When the data labels corresponding to the target feature dimensions in the target data analysis scenario are continuously distributed over time, the test type of the target data analysis scenario is determined based on whether there are preset abnormal fields in the project information of the target test item, and / or whether each parameter in the test conditions corresponding to the data of the target feature dimension exceeds the corresponding parameter range. The test type includes normal test or abnormal test. The target data analysis scenario is determined through an interactive interface. The data corresponding to the target feature dimension is retrieved from the data warehouse model using the data selection strategy corresponding to the test type.

2. The method for processing battery test data according to claim 1, characterized in that, The process involves generating multiple related data tables based on the battery test data corresponding to the target test items, including: Perform data cleaning on the battery test data corresponding to the target test items; Based on the table granularity information corresponding to the target test item and the battery test data after data cleaning, multiple data tables are generated. The table granularity information is used to record the preset granularity of different data tables corresponding to the target test item. The same association key is stored in at least two of the multiple data tables, and the association key is used to establish an association relationship between the at least two data tables.

3. The method for processing battery test data according to claim 1, characterized in that, The process of generating scene analysis data corresponding to the target test item based on each feature dimension and the corresponding data labels includes: Based on each feature dimension and the corresponding data label, the feature dimensions are arranged and combined to obtain a variety of data analysis scenario combinations; each data analysis scenario combination includes at least one feature dimension and the corresponding data label. From the various combinations of data analysis scenarios, select the target data analysis scenario combinations that can display the analysis results in chart form; Determine the appropriate chart type for each of the target data analysis scenario combinations; The scenario analysis data is generated based on the combination of target data analysis scenarios and the corresponding chart types.

4. The method for processing battery test data according to any one of claims 1-3, characterized in that, The method further includes: The user-selected target data analysis scenario is determined through the interactive interface; The interactive interface displays the chart types corresponding to the target data analysis scenario; The target chart type selected by the user from the displayed chart types is determined through the interactive interface; Data corresponding to the target feature dimensions included in the target data analysis scenario are retrieved from the data warehouse model, a chart of the target chart type is generated, and the chart is displayed on the interactive interface.

5. The method for processing battery test data according to claim 4, characterized in that, The process of determining the target data analysis scenario selected by the user through the interactive interface includes: The user-submitted first analysis dimension is obtained through the interactive interface, where the first analysis dimension is any one of the feature dimensions. Based on the scenario analysis data and the first analysis dimension, determine each second analysis dimension that can be combined with the first analysis dimension to form a data analysis scenario combination; The second analysis dimension is displayed in the interactive interface, and the target second analysis dimension selected by the user from the interactive interface is received. The data analysis scenario that includes the first analysis dimension and the target second analysis dimension is combined to determine the target data analysis scenario.

6. The method for processing battery test data according to claim 1, characterized in that, The step of retrieving data corresponding to the target feature dimension from the data warehouse model using the data selection strategy corresponding to the test type includes: Based on the fact that the test type is the normal test, the time period corresponding to the data under the target feature dimension in the data warehouse model is divided into multiple sampling windows; Based on the data corresponding to the target feature dimension within each sampling window, obtain the statistical indicators corresponding to each sampling window respectively; Based on the statistical indicators corresponding to each sampling window, the sampling threshold is determined; Based on the sampling threshold and the statistical indicators corresponding to each sampling window, the window category to which each sampling window belongs is determined. Based on the window category to which each sampling window belongs, data corresponding to the target feature dimension is retrieved from each sampling window.

7. The method for processing battery test data according to claim 4, characterized in that, The step of retrieving data corresponding to the target feature dimension from the data warehouse model using the data selection strategy corresponding to the test type includes: Based on the fact that the test type is the normal test, the target data processing template corresponding to the target chart type is obtained from the preset mapping relationship between chart types and data processing templates; The target data processing template is used to retrieve the data corresponding to the target feature dimension from the data warehouse model.

8. The method for processing battery test data according to claim 1, characterized in that, The step of retrieving data corresponding to the target feature dimension from the data warehouse model using the data selection strategy corresponding to the test type includes: Based on the fact that the test type is the anomaly test, the time period corresponding to the data under the target feature dimension in the data warehouse model is divided into multiple sampling windows; For any two adjacent windows in the plurality of sampling windows, calculate the month-on-month change rate of the target feature data between the two adjacent windows, where the target feature data is the data of the target feature dimension within the corresponding window; Based on the year-on-year change rate between each pair of adjacent windows, the abnormal event window is determined from the plurality of sampling windows; Retrieve all target feature data from the abnormal event window in the data warehouse model, and retrieve the statistical values ​​of target feature data from the remaining sampling windows excluding the abnormal event window.

9. A battery test data processing device, characterized in that, include: The first generation module is used to generate multiple data tables with related relationships based on the battery test data corresponding to the target test items. The determination module is used to assign corresponding data labels to each feature dimension based on the temporal distribution pattern of feature data under each feature dimension in the battery test data. The data labels are used to characterize the continuity of the corresponding feature dimension. The temporal distribution pattern includes time-independent and time-dependent patterns. The time-dependent patterns include continuous distribution over time and discrete occurrence within the test period. The second generation module is used to establish a data warehouse model corresponding to the target test item based on the multiple data tables. Furthermore, based on each feature dimension and the corresponding data labels, scenario analysis data corresponding to the target test item is generated, wherein the scenario analysis data represents the chart types generated for different data analysis scenarios; When the data labels corresponding to the target feature dimensions in the target data analysis scenario are continuously distributed over time, the test type of the target data analysis scenario is determined based on whether there are preset abnormal fields in the project information of the target test item, and / or whether each parameter in the test conditions corresponding to the data of the target feature dimension exceeds the corresponding parameter range. The test type includes normal test or abnormal test. The target data analysis scenario is determined through an interactive interface. The data corresponding to the target feature dimension is retrieved from the data warehouse model using the data selection strategy corresponding to the test type.

10. An electronic device, characterized in that, It includes a memory, a processor, and a computer program stored in the memory and executable on the processor, the processor executing the computer program to implement the method as claimed in any one of claims 1-8.

11. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that is executed by a processor to implement the method of any one of claims 1-8.

12. A computer program product, characterized in that, Includes a computer program, which is executed by a processor to implement the method of any one of claims 1-8.

Images