Methods for managing test data recorded during mass scale cycling of secondary cells

Abstract

The present disclosure generally pertains to testing of secondary batteries More specifically, the disclosure relates to a database structure for storing test data recorded during mass scale cycling of secondary cells. The database structure comprises a first database table (201), a second database table (202) and a third database table (203). The first database table comprising test data collected during individual runs involving charging and discharging secondary cells under different test conditions, wherein test data of the individual runs are stored in the first database table (201) together with a corresponding test identifier and a test recipe identifier. The second database table (202) comprising test recipes, wherein each test recipe comprises a set of individual steps to be performed, settings associated with test conditions of the individual steps and a recipe identifier. The third database table (203) comprising test quality data representative of alignment between test data of an individual test and the corresponding test recipe, wherein the quality data for an individual run is stored in the third database table together with a corresponding test identifier. The disclosure also relates to methods for providing and managing test data recorded during mass scale testing of secondary cells. The disclosure also relates to test equipment and a control arrangement for performing the proposed methods.

Description

[0001] METHODS FOR MANAGING TEST DATA RECORDED DURING MASS SCALE CYCLING OF SECONDARY CELLS

[0002] TECHNICAL FIELD

[0003] The present disclosure generally pertains to testing of secondary batteries. More specifically, the disclosure relates to methods for providing and managing test data recorded during mass scale testing of secondary cells. The disclosure also relates to test equipment and a control arrangement for performing the proposed methods.

[0004] BACKGROUND

[0005] In addressing climate change there is an increasing demand for rechargeable batteries, e.g., to enable electrification of transportation and to supplement renewable energy. Currently, lithium-ion batteries are becoming increasingly popular. Lithium-ion batteries represent a type of rechargeable battery in which lithium ions move from the negative electrode to the positive electrode during discharge and back when charging.

[0006] A rechargeable battery, also referred to as a secondary battery, comprises one or more secondary cells, for example lithium-ion cells. During production of secondary cells, test procedures need to be performed in order to obtain essential characteristics of the lithium-ion cells regarding capacity, power density, energy density, storage life and cycle life. These tests are commonly referred to as Performance and Lifecycle, P&L, tests.

[0007] Due to mass scale production and increased quality requirements, it is foreseen that within a near future mass scale P&L testing will be required at the manufacturing site. This will generate new demands on managing data recorded during the P&L testing.

[0008] The test equipment available typically comprises a user interface that enable users to create, update and delete recipes for testing individual cells. Specific variables to be measured during cycling can also be set via the user interface. An operator may start, pause, and stop the cycling via the user interface. Data from the individual test cycles are commonly provided in a data file after the test is completed. The current solution is time-consuming and resource intensive as the provided data is not suitable for further processing and storing. Hence, there is a need for new ways of handing data recorded during mass scale production of secondary cells.

[0009] SUMMARY

[0010] The present disclosure aims at creating a data pipeline for managing data collected while performing tests on secondary cells, as well as meta data related to the operation of test equipment used. It is a further objective that the data pipeline should make test information and results easily available to interested parties, enable machine learning modelling and analysis using large amounts of data. Further objectives involve more efficient operation of test & validation laboratories, reduced results reporting time, enabling scaling of the data management and possibility to link test results to process data.

[0011] According to a first aspect the disclosure relates to a method, for use in a data management system, for managing test data recorded during mass scale testing of secondary cells, wherein the mass scale testing involves a plurality of runs, wherein each run comprises charging and / or discharging a secondary cell under different test conditions using test equipment. The steps listed below are performed for each of a plurality of individual runs. More specifically, the method comprises receiving, from the test equipment, a data batch comprising test data recorded while performing an individual run and a recipe identifier corresponding to the run. The method further comprises storing the test data together with a test identifier and the recipe identifier in a first database table. The method also comprises receiving, from the test equipment, recipe information corresponding to the recipe identifier. The recipe information comprises a set of individual steps performed during the run and settings associated with the test conditions of the individual steps. The method further comprises storing the recipe identifier and the associated test recipe identifier in a second database table. The method further comprises generating, based on the test data and the test recipe, quality data representative of alignment between the test recipe and the test data. The method finally comprises storing the generated quality data together with a test identifier in a third database table. The proposed method results in a database where data may be accessed in an efficient way for various purposes, as data can be filtered via initial queries in the second and third database tables. Because data from many runs are stored in the same format in one database it enables exporting data for performing modelling or analysis of multiple runs or cycles. This is typically useful for prediction of lifetime and errors. The database also enables exporting data in a format suitable for directly creating graphs of results of multiple runs or cycles. The method can be used for storing huge amounts of data in the first database table and the additional tables makes it possible to manage large data volumes.

[0012] In some embodiments, the data batch comprises data segments representing observations at predefined sampling times during the run, wherein the individual data segments comprise a time stamp and corresponding test data arranged according to a predefined format. Because data is received in batches the method is scalable and thereby suitable for mass scale production.

[0013] In some embodiments, the test data comprises one or more of test environment data, cell data and test meta data. Hence, the method can be used for any type of relevant test data.

[0014] In some embodiments, the method comprises generating, based on the test data, aggregated test data for individual steps of the run and storing the generated aggregated test data together with a test identifier in a fourth database table. By using an aggregation table in combination with the other tables the data volume may be reduced when exporting data from the data management system. This makes it faster and easier to find commonly used measurements / features in the data

[0015] In some embodiments, the generating quality data comprises identifying missing test data, duplicates, incorrect timing, recipe deviations, cell issues and / or test environment issues. Hence, the quality data may be used to identify a variety of issues.

[0016] In some embodiments, the recipe information comprises a plan defining one or more steps, step specifications, version, and / or intended cell information. Hence, the recipe may contain relevant information about a run, which can be used to filter data.

[0017] In some embodiments, the method further comprises receiving a first query at the second and / or third, or fourth if available, database table, the first query comprising, a must clause indicating that database records returned by the first query must fulfil first predefined criteria at a certain column of the second or third, or fourth database table. In these embodiments, the method further comprises providing, in response to the first query, a response identifying recipes, runs or steps fulfilling the predefined criteria, receiving a second query at the first database table, the second query identifying runs or steps identified based on the first query, and providing, in response to the second query, a response comprising test data corresponding to the identified runs or steps runs or steps. Hence, selections of data from the first database table can be selected based on queries in the other tables. Benefits of being able to select a subset of the data is efficiency, time required to download data as well as more precise results.

[0018] In some embodiments the predefined criteria comprises quality criteria, test type criteria and / or recipe criteria. Thus, the data can be filtered based on various criteria.

[0019] According to a second aspect, the disclosure relates to database management system for managing test data recorded during mass scale testing of secondary cells, the database management system comprising a hardware processor; and a machine- readable medium comprising instructions thereon that, when executed by the hardware processor, cause the hardware processor to perform operations according to the first aspect.

[0020] According to a third aspect, the disclosure relates to method for operating test equipment configured to test secondary cells under different test conditions. The method comprises obtaining instructions to perform a run comprising charging and discharging a secondary cell and storing a recipe identifier corresponding to the obtained instructions. The method further comprises executing the run according to the instructions and recording test data during the run and providing, to a data management system, a data batch including the recorded test data and the recipe identifier. The method further comprises providing, to the data management system, recipe information corresponding to the recipe identifier, wherein the recipe information comprises a set of individual steps performed during the run and settings associated with the test conditions of the individual steps. Thereby, the method according to the first aspect is enabled in the data management system.

[0021] In some embodiments, the data batch comprises data segments representing observations at predefined sampling times during the run, wherein the individual data segments comprise a time stamp and corresponding test data arranged according to a predefined format. Hence, the data provided by the test equipment is adapted for storage in the first database table.

[0022] According to a fourth aspect, the disclosure relates to a database structure for storing test data recorded during mass scale cycling of secondary cells. The database structure comprises a first database table, a second database table and a third database table. The first database table comprising test data collected during individual runs involving charging and discharging secondary cells under different test conditions, wherein test data of the individual runs are stored in the first database table together with a corresponding test identifier and a test recipe identifier. The second database table comprising test recipes, wherein each test recipe comprises a set of individual steps to be performed, settings associated with test conditions of the individual steps and a recipe identifier. The third database table comprising test quality data representative of alignment between test data of an individual test and the corresponding test recipe, wherein the quality data for an individual run is stored in the third database table together with a corresponding test identifier. The database structure enables data analysis of data recorded during mas scale production of secondary cells.

[0023] According to a fifth aspect, the disclosure relates to a computer program comprising instructions which, when the program is executed by a computer, cause the computer to carry out the method according to the first or second aspect.

[0024] According to a sixth aspect, the disclosure relates to a computer-readable medium comprising instructions which, when executed by a computer, cause the computer to carry out the method according to the first or second aspect.

[0025] BRIEF DESCRIPTION OF THE DRAWINGS

[0026] The embodiments disclosed herein are illustrated by way of example, and by not by way of limitation, in the figures of the accompanying drawings. Like reference numerals refer to corresponding parts throughout the drawings, in which

[0027] Fig. 1 illustrates example test equipment for mass scale testing of secondary cells. Fig. 2 illustrates electrical couplings of the test equipment. Fig. 3 illustrates a data management system for managing test data recorded during mass scale testing of secondary cells.

[0028] Fig. 4 illustrates communication between the control arrangement (Fig. 7) and the data management system (Fig. 3).

[0029] Fig. 5 illustrate the method for operating test equipment configured to test secondary cells under different test conditions according to the second aspect.

[0030] Figs. 6a-6b illustrate a method for managing test data recorded during mass scale testing of secondary cells according to the first aspect.

[0031] Fig. 7 illustrates a control arrangement of the test equipment of Fig. 2 in further detail.

[0032] DETAILED DESCRIPTION

[0033] This disclosure introduces methods for managing test data recorded during mass scale production of secondary cells. More specifically, the proposed technique provides methods for providing and storing the test data such that relevant data can be accessed in an efficient and convenient way for a plurality of different purposes.

[0034] Embodiments of the present disclosure will now be described more fully hereinafter, with reference to Figs 1 to 7. The same reference numbers are used throughout the figures. The invention may, however, be embodied in many different forms and should not be construed as limited to the embodiments set forth herein; rather, these embodiments are provided by way of example so that this disclosure will be thorough and complete, and will fully convey the scope of the invention to those persons skilled in the art.

[0035] Fig. 1 illustrates example test equipment for mass scale testing of secondary cells. Cell testing typically involves attaching secondary cells placed in a controlled test environment, such as a temperature chamber, to a battery tester (commonly called cycler 30). In the illustrated example, the test equipment 100 is a movable walk-in chamber that comprises an enclosure 101 which forms one (huge) thermally isolated temperature chamber. The enclosure 101 can accommodate thousands of cells 20 (herein also simply called cells 20) in racking 105 arranged along inner walls of the enclosure 101. The cyclers 30 performing the testing can be connected to poles of cells inserted in the racking via cycler interfaces 106 (Fig. 2) arranged on outer walls of the enclosure. Fig. 2 illustrates electrical components and couplings of the test equipment, such as cycler interfaces 106, cabling 107 and a control arrangement 10, in more detail. In some embodiments, the test equipment 100 additionally comprises further electrical components such as a power storage 1 12, at least one central power connector 1 10, a wireless access point 1 14, one or more sensors 1 1 1 and a user interface 108. Note that the cabling arranged to connect the cyclers 30 to poles of secondary cells 20, also referred to as channels, is not shown in Fig. 2.

[0036] The cabling 107 comprises electrical conductors arranged to connect the electrical components of the test equipment 100. The cabling 107 comprises power cabling 107a (thick line) and communication cabling 107b (dashed line). In some embodiments, the cabling 107 is at least partly integrated in walls of the enclosure 101 . Some cabling 107, such as the power cabling 107a or the communication cabling 107c, may also extend along the outer walls, as it does not need to be connected to the cells 20 located inside the enclosure 101 .

[0037] The power cabling 107a is arranged to connect power interfaces of the cycler interfaces 106 to the power storage 1 12 and / or to the at least one central power connector 1 10, via an AC / DC converter. The communication cabling 107b is arranged to connect various components to the control arrangement 10. In some embodiments, the communication cabling 107b is also configured to connect the control arrangement to cyclers 30 connected to the cycler interfaces 106 and to a common user interface 108. In other words, in some embodiments, the cabling 107b is arranged to connect each cycler interface 106 to a central user interface 108 whereby cyclers 30 connected to the cycler interfaces 106 can be controlled from the central user interface 108. For example, the user interface can be used by an operator to initiate tests and create or select recipes.

[0038] The communication cabling 107b may also connect a temperature and / or climate control mechanism 109 (Fig. 1 ) to the control arrangement 10, whereby the control arrangement 10 can control the temperature and / or climate control mechanism 109. In some embodiments, the communication cabling 107b is arranged to connect the one or more sensors 1 1 1 to the control arrangement 10, such that the control arrangement 10 may receive sensor data representing environmental data of the testing. The sensor data may be indicative of various parameters relevant to testing, such as temperature, humidity etc. in the enclosure 101 or temperature or energy level at the cell interfaces 106. The communication cabling 107b may also be connected to the wireless access point 114. The wireless access point is for example a wireless router that may enable wireless communication using e.g., WiFi or any 3GPP standard inside the enclosure 101 .

[0039] Fig. 3 illustrates a data management system 200 for managing test data recorded during mass scale testing of secondary cells. The database management system is a unit in a functional sense and may be implemented as a cloud service or similar. The data management system 200 is configured to receive and store test data recorded during mass scale testing of secondary cells, using the method described below with reference to Fig. 6a. The data management system 200 comprises a processor 21 , memory 22 and a communication interface 13.

[0040] The processor 21 is basically a computer. In other words, the processor 21 herein refers to hardware or hardware / firmware device implemented using processing circuity such as, but not limited to, a processor, Central Processing Unit (CPU), a controller, an arithmetic logic unit (ALU), a digital signal processor, a microcomputer, a field programmable gate array (FPGA), a System-on-Chip (SoC), a programmable logic unit, a microprocessor, an application-specific integrated circuit, or any other device capable of electronically performing operations in a defined manner.

[0041] The memory 22 (or computer-readable medium) herein refers to any non-transitory computer-readable medium, such as a tangible electronic, magnetic, optical, infrared, electromagnetic, and / or semiconductor system, apparatus, and / or device. The memory 22 comprises a database for storing recipe test data, as well as memory for storing a data program configured to perform the methods for managing data described herein. The database has database structure for dividing the database into tables and defining relationships between them to minimize redundancy and dependency.

[0042] The communication interface 23 may be implemented using any suitable wired or wireless communication protocol, such as Ethernet (internet protocol), 3GPP standards, WiFi etc. The communication interface 23 enables communication between the data management system 200 and the control arrangement 10 of the test equipment 100.

[0043] During the test, the test data is recorded by the test equipment 100 and provided to the management system 200, either directly or via some server. The recording may involve recording sensor data and collecting other data associated with the test. The test data may be recorded with periodic intervals, such as every second. The intervals may be configurable, e.g. by the recipe. Also an aperiodic sampling scheme may be used. For each periodic time stamp a plurality of parameters may be reported. Data belonging to one time stamp is herein called an observation. The test data may be raw (i.e., unprocessed) test data or processed. In some embodiments the test data comprises one or more of test environment data, cell data and test meta data.

[0044] Test environment data herein refer to data describing the test environment. The data may be measurements or settings / configurations. The test environment data comprises for example, chamber temperature, humidity or pressure. The test environment data may also include hardware ID of the test equipment, staff information, etc.

[0045] Cell data herein refer to data describing the cell under test. The cell data may include measurements, such as cell temperature, internal resistance, voltage, and current. The cell data may also include estimated or predefined cell metrics and other relevant data such as power, charge capacity etc.

[0046] Test meta data herein refer to any data that helps to organize, find and understand the test data. Test meta data may also include data defining the test performed. Examples of test meta data include measurement time stamp, cell ID, cycle count, step ID, step type, test status of step (e.g., done or aborted), test validity, test mode, staff and hardware, staleness, operating mode. A cycle herein refers to one charge and discharge cycle. A run herein refers to a sequence of test steps specified by a certain test plan. A step is, for example, an individual activity or action. A run typically has a start and a stop. A run could last for minutes to months or even years. Long runs could typically be interrupted and restarted, e.g., based on something going wrong. The data management system 200 is configured to receive and store all these types of test data in a structured way that enable easy access. In the proposed database structure, the test data is stored in a first database table 201 . In other words, the proposed database structure comprises a first database table 201 comprising test data collected during individual runs involving charging and discharging secondary cells under different test conditions, wherein test data of the individual runs are stored in the first database table together with a corresponding test identifier, ID, and a test recipe ID. For example, each row in the table corresponds to one observation and the first column may comprise a time stamp of the observation, the second column the test ID and the third column the recipe ID. Individual types of test data is then stored in other columns, one column per type of data. The rows may be sorted based on time stamp.

[0047] The test data typically comprises an exceptionally large amount of data, as it typically comprises one data segment with many measurements etc., for each sample time. In other words, one segment may correspond to parameters associated with one observation in time.

[0048] As many cells undergo testing, the data management system 200 receives huge batches of test data from the test equipment 100. The proposed technique is based on the insight that the huge amount of data recorded during multiple runs should be stored in such a way that data can be accessed at a later point in time for different purposes. In particular there need to be a way to navigate in the huge amount of test data stored in the first database table 201 . Here the inventors have realised that there are particular parameters of a test that is typically of specific interest when querying test data from this type of database. The most important parameters are test recipe (i.e. what test was performed) and test quality (i.e. what was the outcome). Hence, the technique proposed herein comprises a method for structuring the database such that it is possible to identify and fetch data corresponding to specific test steps and / or corresponding to specific quality requirements. To make this possible the test equipment 100 should not only provide the test data describing the actual outcome of the test, but also needs to provide detailed recipe information describing how the test was intended to be performed. In other words, the data management system 200 should receive both test data 210 and recipe information 220 from the test equipment 100. In some embodiments the received recipe information comprises one or more of; a plan, step specifications, version and intended cell information. The plan identifies one or more steps to be performed. For example, the plan may include step IDs, step type, maximum iteration values etc. The step specifications may define such as plan categories, targets, limits, set variables as well as intended start / end state of charge. The recipe may also include normative measures such as C-rate, which is a measurement of the rate at which a battery is discharged comparable to its full capacity. The version defines a version of the recipe or of a plan, as an individual recipe or plan may be updated over time. The reason is that plans may be copied and used in another recipe. The version number may be automatically generated when changes are made to the recipe (or plans). The version may also include a time stamp identifying a point in time when changes were made, i.e., of the version. The intended cell information describes the type of cell that is to be tested, such as cylindrical or prismatic, voltage, capacity etc.

[0049] It is herein proposed that test recipes are stored in the second database table 202 in the data management system 200. For example, each row in the table corresponds to one recipe ID, version and step ID and the first column may comprise the recipe ID (e.g., a name). Individual parameters / settings may then be stored in other columns, one columns per type of parameter, for example, plan ID and plan version. In other words, the proposed database structure comprises a second database table 202 comprising test recipes, wherein each test recipe comprises a set of individual steps to be performed, settings associated with test conditions of the individual steps and a recipe identifier, ID. In other words, the second database table stores recipe IDs together with corresponding recipe information.

[0050] As the number of recipes is naturally much smaller than the number of time stamps this table will be much smaller than the first database table 201 . Hence, the second database table can be used to search for specific test sequences or settings in order to identify tests comprising such test data. More specifically, the second database table 202 can be used to identify a recipe id of recipes comprising a certain sequence or setting. For example, the recipe ID and version (and possibly step ID) can then be used in a query in the first database table to access corresponding raw data. Based on the test data 210 and / or the recipe information 220 a new type of data, herein called quality data, may be produced. The quality data is for example data that describes how well the test data matches with the recipe information. For example, quality data may be obtained by comparing settings corresponding to a test recipe with actual measurement performed during a corresponding test. The quality data may for example indicate is the actual temperature matches a set temperature. It is herein proposed that quality data is stored in a third database table in the database. The third database table can be used to filter out data that does not have sufficient quality. This may be crucial when using the database for modeling and machine learning as training data should typically exclude outliers caused by the test process. In other words, the database structure comprises a third database table 203 comprising test quality data representative of alignment between test data of an individual test and the corresponding test recipe, wherein the quality data for an individual run is stored in the third database table 203 together with a corresponding test identifier. Together herein means that there is an identifiable relation in the database between the recipe ID and the corresponding data. For example, rows in the third database represent steps that matches a certain quality query (positive or negative) and the result of the query. Hence, the rows may comprise steps with a quality issue, such as actual voltage target being below / or above a set voltage target. The generation of quality data and the quality data is described in further detail in Fig. 6a, below.

[0051] In addition, the database structure may include an aggregation table, herein referred to as the fourth database table 204. An aggregation table is a database tables that contain aggregated values of another table, here the first database table. As the first database table 201 typically comprises all available test data it is typically feasible to have an aggregated table that only comprises a selection of the time stamps of each step. The aggregation table may for example comprise step summaries, such as medium, max an min values for each step.

[0052] Fig. 4 illustrates communication between the test equipment 100 (Figs. 1 -2) and the data management system 200 (Fig. 3) when performing the proposed methods. The method results in a database structure that fulfils one or more of the above-mentioned objects. The signalling diagram of Fig. 4 involves steps performed both in the test equipment 100 as well as in the data management system 200. Hence, the proposed technique requires implementation in both the test equipment 100 and in the data management system 200. Fig. 5 is a flow chart of the proposed method for operating test equipment (Figs. 1 -2) configured to test secondary cells under different test conditions according to the second aspect. Figs. 6a-6b illustrate the corresponding method, for use in a data management system (200), for managing test data recorded during mass scale testing of secondary cells. It should be appreciated that some of the steps involving receiving and storing data may be performed in reverse order while achieving the same database structure.

[0053] The methods may be implemented as a computer program comprising instructions which, when the program is executed by a computer (e.g., a processor in the control arrangement 10 (Fig. 2) or data management system (Fig. 3)), cause the computer to carry out the method. According to some embodiments the computer program is stored in a computer-readable medium (e.g., a memory or a compact disc) that comprises instructions which, when executed by a computer, cause the computer to carry out the method. In some embodiments, the method is implemented in a control arrangement 10 of test equipment 100, e.g., in the walk-in chamber of Fig. 1. The method is typically performed during testing secondary cells. The proposed method will now be described with reference to Figs. 4-6 as well as to the other Figs.

[0054] Tests may be initiated in different ways, such as by an operator providing instructions via a user interface 108, or automatically by some automatic controller device. Mass scale testing involves a plurality of runs, wherein each run comprises charging and / or discharging a secondary cell under different test conditions using test equipment. The tests may involve cell cycling, which means that a cell is charged and discharged. The tests may also involve Reference Performance Testing, RPT, which focuses on how cells performs under specific loads or conditions. A reference performance test will typically yield capacity fade, power fade, and impedance rise as a function of test time. The operator can typically initiate testing of a plurality of cells simultaneously. This is then performed repeatedly while testing is needed. In other embodiments testing is started automatically. It must be appreciated that many tests may be running simultaneously and started and stopped at different points in time. The proposed methods may be performed for every run initiated by the system. For each such run, the method performed in test equipment (Fig. 5) comprises obtaining S1 instructions to perform a run comprising charging and discharging a secondary cell. The instructions may be received via the user interface 108 or via a communication interface, such as the wireless access point 1 14. The instructions may comprise a recipe ID, such as a recipe name or number, which identifies the tests to be performed as described above. Alternatively, a new recipe may be programmed, i.e., created, when initiating the run. In these embodiments, a new recipe ID will also be created, for example provided by the operator. The recipe ID may be a name or number assigned via the user interface 108. The new (or already existing) recipe ID is stored in the test equipment with a version number. An already existing recipe may also be updated and stored by a new version number. Thereby, recipe ID and corresponding information can be provided to the data management system 200 and reused and accessed. In other words, the method performed in test equipment (Fig. 5) comprises storing S2 a recipe identifier corresponding to the obtained instructions.

[0055] The testing is then executed in accordance with the instructions. This may involve charging and discharging a cell multiple times under conditions specified by the recipe. The test equipment 100 will also control the test environment based on the recipe. In some embodiments, the test is assigned a unique test ID. In other words, the method performed in test equipment (Fig. 5) comprises executing S3 the run according to the instructions and recording test data during the run.

[0056] Test data is then reported to the data management system 200. This may both be done during and after the testing. For example, it may be streamed or sent in batches. The test data is reported together with a recipe ID, which identifies the instructions obtained in step S1 and typically also the test ID. In other words, the method performed in test equipment (Fig. 5) comprises providing S4, to a data management system 200, a data batch including the recorded test data and the recipe identifier. The method performed in the data management system comprises receiving S1 1 , from the test equipment 100, a data batch comprising test data 210 recorded while performing an individual run and a recipe identifier, ID, corresponding to the run. In some embodiments several batches are provided and received per run. The batches may be delivered as batches or streamed as data becomes available. The test data may also be stored in an intermediate storage between the test equipment and the data management system 200.

[0057] In order for the data management system to be able to interpret the data. The data should have a certain format. The test equipment 100 may provide the test data in different formats. In some embodiments the recipe information is provided together with the test data. In other embodiments the recipe information is provided separately, such as via a different interface. The test data may be divided into data batches, also called payloads. For example, one or several batches are provided per run. For a run that has a duration of one week there may for example be one payload delivered every second hour. In other words, in some embodiments, the data batch comprises data segments representing observations at predefined sampling times during the run, wherein the individual data segments comprise a time stamp and corresponding test data arranged according to a predefined format. In other words, in some embodiments, one data batch comprises data segments representing observations at predefined sampling times during the run, wherein the individual data segments (i.e., observations) comprise a time stamp and corresponding test data arranged according to a predefined format. The test data typically also comprises meta data that makes it possible to interpret and organize the data, as described above. In particular each observation may comprise a cell ID, a step ID and an iteration / cycle number.

[0058] The test data is then stored in the data management system 200 together with the recipe ID. The test data is stored together with the recipe ID, which makes it possible to at a later point in time query specific sequences etc., which will be described below. The test data is stored in a first database table 201. In other words, the method performed in the data management system (Fig. 6a) 200 comprises storing S12 the test data together with a test identifier and a recipe identifier in a first database table 201.

[0059] In some embodiments an aggregation table is also generated and stored. In other words, in some embodiments, the method performed in the data management system (Fig. 6a) comprises generating S13, based on the test data, aggregated test data for individual steps of the run. In some embodiments, the method performed in the data management system (Fig. 6a) comprises storing S14 the generated aggregated test data together with a test identifier in a fourth database table 204.

[0060] The test equipment 100 also provides the recipe information to the data management system 200. The recipe information may either be sent separately, or it may be attached to a batch of test data. In the latter case, the receiving / providing S16 / S6 recipe information may then be merged with the step of receiving / providing S1 1 , S4 test data. For example, the recipe information may be included in the batches of data. If the same recipe is used several times, it only has to be sent once, sometimes based on a request S15 from the data management system 200. In some embodiments, the same recipe information is sent many times. In some embodiments the test data is sent or retrieved over a separate interface. In other words, the method performed in test equipment (Fig. 5) comprises providing S5, to a data management system 200, recipe information corresponding to the recipe identifier. The recipe information comprises a set of individual steps performed during the run, and settings associated with the test conditions of the individual steps, as described above. The method performed in the data management system (Fig. 6a) comprises receiving S16, from the test equipment, recipe information corresponding to the recipe identifier. If the same recipe is received many times only one copy has to be kept. If there are several versions of the same recipe, all versions or the differences should be stored in the second database table 202. In other words, the method performed in the data management system (Fig. 6a) comprises storing S17 the recipe identifier and the associated test recipe identifier in a second database table 202.

[0061] Quality data is then generated based on the test data and the recipe. The quality data is data indicative of the quality of a step or test. Generating quality data may involve comparing the test data and the recipe information, such as comparing corresponding values. It may also involve analyzing the test data to identify mismatches, errors and suspicious values, which could not be caused by the cell under test. In other words, the method performed in the data management system (Fig. 6a) comprises generating S18, based on the test data and the test recipe, quality data representative of alignment between the test recipe and the test data. Some examples of various issues and deviations that may be indicated in the quality data will now be described. The quality data may for example indicate when test data is missing. For example, missing DCIR measurement values, capacity measurement or plan specifier values may be crucial when data is used for certain purposes. Thus, it may be desirable to be able to filter out observations where this data is missing. In other words, in some embodiments, the generating S18 quality data comprises identifying missing test data.

[0062] It may also happen that a test is interrupted and restarted, which may cause an overlap of certain steps. Thus, there may be duplicates of certain steps of a test. In such a scenario it may be desirable to filter out those steps. Duplicates may be observations having the same run ID, step ID and / or timing information. In other words, in some embodiments, the generating S18 quality data comprises identifying duplicates.

[0063] There may also be quality issues related to the sampling of test data. Such errors may be identified based on sampling rate or gaps in a time series. If there are gaps, the size of such a gap may also be relevant. In other words, in some embodiments, the generating S18 quality data comprises identifying incorrect timing.

[0064] Another quality problem relates to when the test is not performed in accordance with the recipe. For example, there may be deviations between actual current / voltage and target current / voltage target. Such errors may also be indicated in the quality data. In other words, in some embodiments, the generating S18 quality data comprises identifying recipe deviations.

[0065] Quality may also be associated with cell issues, such as low capacity, High DCIR values. In certain scenarios it may be desirable to filter out faulty cells, why this may be indicated in the quality data. In other words, in some embodiments, the generating S18 quality data comprises identifying cell issues.

[0066] There may also be specifics related to the test environment, such as abnormal temperature or hardware errors, which are relevant to trace. In other words, in some embodiments, the generating S18 quality data comprises identifying test environment issues. The generated quality data is then stored in a separate table. In other words, the method performed in the data management system (Fig. 6a) comprises storing S19 the generated quality data together with a test identifier in a third database table 204.

[0067] The steps S1 1 -S19 shown in Fig. 6a are then performed in an ongoing manner as testing proceeds. The database created can then be accessed for various purposes, both by personnel in the factory as well as by researchers, see Fig. 6b.

[0068] The data management system is further configured to receive queries and provide corresponding data from the database. The database structure including the specified tables may be implemented using a standard Relational Database Service running in the cloud. The tables may be virtual tables, also called views, or other equivalent structure for storing data. The specific queries to be made depend on what data is to be used for. Some examples are provided below with reference to Fig. 6b.

[0069] As explained above, the second, third and fourth database tables 202-204 are intended to be used to manage the raw data stored in the first database table 201 . In other words, in some embodiments, the method performed in the data management system (Fig. 6b) further comprises receiving S20 a first query at the second and / or third, or fourth if available, database table. The first query typically comprises a must clause indicating that database records returned by the first query must fulfil first predefined criteria at a certain column of the second or third, or fourth database table. The must clause could for example define records that should be filtered out. Alternatively, it may define criteria to be selected. Hence, the following steps are typically performed in order to export a set of data from the database.

[0070] In a first example, one may filter runs or steps with quality issues prior to export. The quality criteria may depend on what the data set is to be used for. For example, one may want to predict lifetime of cells, in such a scenario on may want to filter out all tests where there may be issues caused by the test environment or test setup. One may also want to filter out stale or aborted steps. This may either be because it is not wanted or because you want to investigate cases where the experiments were paused, restarted or aborted entirely in further detail. In other words, in some embodiments, the predefined criteria comprises quality criteria. In a further example, one may want to identify data comprising specific test sections, i.e. steps or plans, for example reference performance test or cycling. Hence, one may look for particular values of a plan specifier, such as cycling or RPT. In other words, in some embodiments, the predefined criteria comprises test type criteria.

[0071] In another example, one may want to filter runs with the same structure, meaning the same recipe or the same specifications in specific important steps such as where the capacity measurement is made. Hence, the first query may define criteria defining the desired structure. In other words, in some embodiments, the predefined criteria comprises recipe criteria.

[0072] The database management system then returns a response to the query. The response could identify relevant recipe IDs, test IDs, step IDs or other parameter of the queried table, which is also present in the first database table 201 . In other words, in some embodiments, the method performed in the data management system (Fig. 6b) further comprises providing S21 , in response to the first query, a response identifying recipes, runs or steps fulfilling the predefined criteria.

[0073] The first query can be repeated several times for different database tables if further filtering is required. Raw data can then be fetched from the first database table based on the results. In other words, in some embodiments, the method performed in the data management system (Fig. 6b) further comprises receiving S22 a second query at the first database table 201 , the second query identifying runs or steps identified based on the first query.

[0074] In this way filtered raw data can then be provided to users of the database. In other words, in some embodiments, the method performed in the data management system (Fig. 6b) further comprises providing S23, in response to the second query, a response comprising test data corresponding to the identified runs or steps runs or steps. The two queries may of course be joined into one single query.

[0075] In a further example, queries for data analysis may involve step level measurement aggregate export instead of exporting entire time series. More specifically, when data of a specific test is exported in step 23 one may choose to instead export only the aggregated data from the fourth database table. Fig. 7 illustrates a control arrangement 10 of the test equipment 100 in further detail. The control arrangement 10 comprises at least one processor 1 1 and memory 12. In general, the electronic user device 2, is configured to perform all embodiments of the method according to the second aspect described herein. This might e.g., be achieved by the processor 1 1 executing software stored in the memory 22. The control arrangement 10 also comprises an interface 13 configured to communicate with the data management system 200. The interface 13 may be implemented using any suitable wired or wireless communication protocol, such as Ethernet (internet protocol), 3GPP standards, WiFi etc.

[0076] The proposed technique has been described with reference to lithium-ion cells, but it should be appreciated that method for other types of cells including cells made from solid state materials, such as graphene. Such cells are expected to be more commonly used in the future.

[0077] The terminology used in the description of the embodiments as illustrated in the accompanying drawings is not intended to be limiting of the described method, control arrangement or computer program. Various changes, substitutions and / or alterations may be made, without departing from disclosure embodiments as defined by the appended claims.

[0078] The term “or” as used herein, is to be interpreted as a mathematical OR, i.e. , as an inclusive disjunction; not as a mathematical exclusive OR (XOR), unless expressly stated otherwise. In addition, the singular forms "a", "an" and "the" are to be interpreted as “at least one”, thus also possibly comprising a plurality of entities of the same kind, unless expressly stated otherwise. It will be further understood that the terms "includes", "comprises", "including" and / or "comprising", specifies the presence of stated features, actions, integers, steps, operations, elements, and / or components, but do not preclude the presence or addition of one or more other features, actions, integers, steps, operations, elements, components, and / or groups thereof. A single unit such as e.g. a processor may fulfil the functions of several items recited in the claims.

Claims

CLAIMS1 . A method, for use in a data management system (200), for managing test data recorded during mass scale testing of secondary cells, wherein the mass scale testing involves a plurality of runs, wherein each run comprises charging and / or discharging a secondary cell under different test conditions using test equipment, the method comprising: for each of a plurality of individual runs, performing the steps of:- receiving (S11 ), from the test equipment (100), a data batch comprising test data (210) recorded while performing an individual run and a recipe identifier corresponding to the run,- storing (S12) the test data together with a test identifier and the recipe identifier in a first database table (201 ),- receiving (S16), from the test equipment, recipe information corresponding to the recipe identifier, wherein the recipe information comprises: o a set of individual steps performed during the run, o settings associated with the test conditions of the individual steps,- storing (S17) the recipe identifier and the associated test recipe identifier in a second database table (202),- generating (S18), based on the test data and the test recipe, quality data representative of alignment between the test recipe and the test data and- storing (S19) the generated quality data together with a test identifier in a third database table (203).

2. The method according to claim 1 , wherein the data batch comprises data segments representing observations at predefined sampling times during the run, wherein the individual data segments comprise a time stamp and corresponding test data arranged according to a predefined format.

3. The method according to claim 2, wherein the test data comprises one or more of: test environment data, cell data, and test meta data.

4. The method according to any one of the preceding claims, comprising:- generating (S18), based on the test data, aggregated test data for individual steps of the run and- storing (S19) the generated aggregated test data together with a test identifier in a fourth database table (204).

5. The method according to any one of the preceding claims, wherein the generating (S18) quality data comprises identifying one or more of:• missing test data,• duplicates,• incorrect timing,• recipe deviations,• cell issues, and• test environment issues.

6. The method according to any one of the preceding claims, wherein the recipe information comprises one or more of:• a plan defining one or more steps,• step specifications,• version, and• intended cell information.

7. The method according to any one of the preceding claims, wherein method further comprises:- receiving a first query at the second and / or third, or fourth if available, database table, the first query comprising, a must clause indicating that database records returned by the first query must fulfil first predefined criteria at a certain column of the second or third, or fourth database table,- providing, in response to the first query, a response identifying recipes, runs or steps fulfilling the predefined criteria,- receiving a second query at the first database table, the second query identifying runs or steps identified based on the first query,- providing, in response to the second query, a response comprising test data corresponding to the identified runs or steps runs or steps.

8. The method according to claim 7, wherein the predefined criteria comprises one or more of:• quality criteria,• test type criteria,• recipe criteria.

9. A database management system (200) for managing test data recorded during mass scale testing of secondary cells, the database management system comprising:• a processor (21 ); and• a machine-readable medium (22) comprising instructions thereon that, when executed by the hardware processor, cause the hardware processor to perform operations of any one of claims 1 -8.

10. A method for operating test equipment (100) configured to test secondary cells under different test conditions, the method comprising:- obtaining (S1) instructions to perform a run comprising charging and discharging a secondary cell,- storing (S2) a recipe identifier corresponding to the obtained instructions,- executing (S3) the run according to the instructions and recording test data during the run,- providing (S4), to a data management system (200), a data batch including the recorded test data and the recipe identifier and- providing (S5), to the data management system (200), recipe information corresponding to the recipe identifier, wherein the recipe information comprises: o a set of individual steps performed during the run, and o settings associated with the test conditions of the individual steps.11 .The method according to claim 10, wherein the recipe information comprises one or more of:• a plan defining one or more steps,• step specifications,• version, and• intended cell information.

12. The method according to claim 10 or 11 , wherein the data batch comprises data segments representing observations at predefined sampling times during the run, wherein the individual data segments comprise a time stamp and corresponding test data arranged according to a predefined format.

13. A database structure for storing test data recorded during mass scale cycling of secondary cells, the database structure comprising:• a first database table (201 ) comprising test data collected during individual runs involving charging and discharging secondary cells under different test conditions, wherein test data of the individual runs are stored in the first database table together with a corresponding test identifier and a test recipe identifier,• a second database table (202) comprising test recipes, wherein each test recipe comprises a set of individual steps to be performed, settings associated with test conditions of the individual steps and a recipe identifier, and• a third database table (203) comprising test quality data representative of alignment between test data of an individual test and the corresponding test recipe, wherein the quality data for an individual run is stored in the third database table together with a corresponding test identifier.

Images