A data flow-based electrochemical energy storage device automatic detection and report generation architecture

Abstract

The application relates to a data flow-based automatic detection and report generation architecture of an electrochemical energy storage device, which comprises an automatic detection architecture: a feature input part, a test flow part and a database table part; the feature input part is used for injecting required device detection feature information into the database table part; the test flow part expresses all detections in a unit threshold type conditional statement: the test mark values of all sub-test items are taken and, and a detection result is obtained; an automatic report generation architecture generates an evaluation report according to the detection result; the data flow architecture provided by the application can complete cloud storage of various test flows of the energy storage device, realizes visualization of detection data in a network environment, and can automatically generate reports respectively for various detection items, so that the proportion of manual links in the generation of detection reports is reduced.

Description

Technical Field

[0001] This invention relates to an automatic detection and report generation architecture for electrochemical energy storage devices based on data flow, belonging to the field of detection technology. Background Technology

[0002] Clean energy is gradually becoming the mainstay of the new power system. The high proportion of new energy sources will significantly increase the demand for electrochemical energy storage equipment, and at the same time, it will also put forward the testing requirements for large-scale electrochemical energy storage equipment from factory delivery to commissioning.

[0003] In energy storage converters, relevant standards are mostly presented as groups of different sub-projects, which are used to determine the testing status of the higher-level projects that include multiple unit test items. At the same time, reports need to be generated for the status of each unit test item and the status of the higher-level projects, which takes up a lot of time manually. Summary of the Invention

[0004] The purpose of this invention is to provide an automatic detection and report generation architecture for electrochemical energy storage devices based on data flow, so as to solve the problems mentioned in the background art.

[0005] The technical solution of the present invention is as follows:

[0006] An architecture for automatic detection and report generation of electrochemical energy storage devices based on data streams, comprising:

[0007] Automated detection architecture: includes feature input section, test process section, and database table section;

[0008] The feature input section is used to inject the required device detection feature information into the database table section;

[0009] The test process section describes all detections using unit threshold conditional statements:

[0010]

[0011] Where (i = 1, 2, ..., m), f i (x) represents the test flag value of the i-th sub-test item. x represents the value of the physical quantity finally detected in a certain test item. If the value is between the upper threshold M and the lower threshold m, it means that the equipment passes the test for that item. If the value is between the upper threshold M and the upper error threshold U, or if the physical quantity is between the lower error threshold u and the lower test threshold m, it means that the test fails. If the physical quantity is greater than the upper error threshold U or less than the lower error threshold u, it means that there is a test error in the test and the test should be rescheduled.

[0012] The test results are obtained by taking the AND operation of the test flag values ​​of all sub-test items;

[0013] Automatic report generation architecture: Generates evaluation reports based on test results.

[0014] Preferably, the feature input section includes a section for manually entering or scanning hardware to inject the required device detection feature information into the database table, and initializing the data stream of device information and test information.

[0015] Preferably, the test process separates the automatic detection process and the manual detection process in the entered data stream, and separates the tests where the detection quantity is outside the error threshold for retesting after debugging.

[0016] Preferably, the data stream introduced by the feature entry section and updated by the test process section will be synchronized with the database table section in real time. The update and synchronization of the data stream will be based on two basic dimensions: different levels of testing and different equipment types. Data streams updated at different times will be entered into the database table system in a certain order.

[0017] Preferably, the database table portion includes a test case database, a platform project database, a test procedure database, a test equipment database, and a registered equipment database.

[0018] Preferably, the test case database contains the call information of all cases in the platform, and the information of the corresponding test cases can be obtained by linking to the external test case database. It contains the data volume of all detection architecture case indexes.

[0019] Preferably, the test procedure database is a standardized test process database for each test device. By referencing the test standards of various electrochemical energy storage devices, the test procedure database tables and stores the test procedures in each standard in a hierarchical manner. It belongs to the test case database and mainly records the test procedures applied to the corresponding type of device.

[0020] Preferably, the registered device database is a database automatically generated for each device after the registration operation is performed; it includes the device's characteristic information and non-characteristic information, and is used as a data source for the automated testing process.

[0021] Preferably, the test equipment database is directly linked to the registered equipment database, which is used to link to the platform project database and provide corresponding test information for the experimental projects being tested.

[0022] Preferably, the platform project database is used to display data on the platform front end, and the platform project database is also linked to the test equipment database and the test case database.

[0023] The present invention has the following beneficial effects:

[0024] This invention constructs a data flow architecture for various electrochemical energy storage devices. By classifying and centralizing manual testing items, automated testing items, and equipment-specific testing items, it significantly increases the automation level of enterprises in the actual testing of various electrochemical energy storage projects such as energy storage converters and energy storage batteries. Simultaneously, the data flow architecture provided by this invention enables cloud storage of various testing processes for energy storage devices, visualization of testing data in a network environment, and automated generation of reports for each testing item, reducing the proportion of manual steps in report generation. Attached Figure Description

[0025] Figure 1 This is a diagram illustrating the detection architecture of the manual detection and experimental detection methods of this invention.

[0026] Figure 2 This is the architecture of the database table portion of the collaborative multi-device type architecture of the present invention;

[0027] Figure 3 This is the form in which the data flow of this invention is represented in the platform project database;

[0028] Figure 4 This is an example of a manual testing interface display page for this invention;

[0029] Figure 5 This refers to the backend MySQL database corresponding to the front-end interface of this invention;

[0030] Figure 6 This is a reference format for the automatic evaluation report of this invention. Detailed Implementation

[0031] The present invention will now be described in detail with reference to the accompanying drawings and specific embodiments.

[0032] Energy storage converters are built upon the hardware requirements of testing items as specified in standards such as GB / T 34133-2017. Through optimized supporting software solutions, they achieve integrated, automated, and diversified factory and type testing with a MySQL database. Energy storage batteries are built upon the testing items as specified in standards such as GB / T 36276-2018. They utilize testing methods for different equipment standards, including individual cells, modules, and clusters, to achieve comprehensive, automated, and diversified testing of energy storage converters.

[0033] This invention is based on the Python framework, using Flask modules and the Jinja2 language to build a front-end web app. The back-end, also based on a Python architecture, interconnects with a MySQL database using an SQLAlchemy module, constructing a data-flow-based architecture for automatic testing and report generation of electrochemical energy storage devices. This system can archive and store equipment data, test requirements, and test results for energy storage converter systems in an online database, and systematically implement type testing procedures for electrochemical energy storage devices, such as energy storage converters and energy storage batteries, according to standards such as GB / T 34133-2017 and GB / T 36276-2018.

[0034] Basic information on each electrochemical energy storage device is archived in a MySQL database. The type testing process architecture for energy storage converters reflects the innovation of this invention in classifying and centrally summarizing manual and automatic testing items in the testing process; the type testing process architecture for energy storage batteries reflects the innovation of this invention in summarizing and processing the type testing of electrochemical energy storage devices.

[0035] Example:

[0036] Automatic detection architecture:

[0037] This invention first establishes a record-keeping system for electrochemical energy storage devices. The device testing parameter information consists of various parameters, including DC-side parameters, AC-side parameters, grid-connected operation parameters, and off-grid operation parameters. The characteristic information includes details such as the model, registration date, and testing items of the specific electrochemical energy storage device. Each participating energy storage converter is assigned a unique identifier to achieve unified planning and management of device information, test content, test data, and test results.

[0038] In type testing, some tests are difficult to automate due to cost or technical reasons, and require manual visual inspection, touch, or the use of other basic tools to take measurements. Therefore, this invention constructs a set of test procedures that are classified, processed, and summarized.

[0039] First, this invention formalizes the different standards for various testing items of electrochemical energy storage devices into formulas, describing all tests using unit threshold-type conditional statements. Each unit threshold-type statement consists of five intervals. The narrowest interval reflects the data requirements specified by the standard, and its two adjacent intervals represent the data ranges of test values ​​for electrochemical energy storage devices that do not meet the standard in most cases. The remaining two intervals, due to their significant deviation from the standard, provide the platform with error correction space for incorrect testing methods or procedures. Figure 1 As shown:

[0040]

[0041] x represents the value of the final detected physical quantity in a certain test item. If this value is between the upper threshold M and the lower threshold m, then the test flag value f is... i If (x) is 1, it means the device passed the test. If the value is between the upper test threshold M and the upper error threshold U, or if the physical quantity is between the lower error threshold u and the lower test threshold m, it means the test failed. If the physical quantity is greater than the upper error threshold U or less than the lower error threshold u, it means there is a test error and the test should be rescheduled. This type of unit threshold conditional statement is used to judge the most basic test unit, thereby determining the three states: test passed, test failed, and test error.

[0042] In energy storage converters, relevant standards are mostly presented as groups of different sub-items, which are used to determine the testing status of higher-level items that include multiple unit test items. Items that fail key tests, such as voltage response, can be considered as combinations of multiple unit items. For a combined test with multiple unit items, its overall logic can be expressed using threshold-type conditional statements for each unit.

[0043] For manual testing items involving binary judgments, such as visual inspection and functional testing, the test threshold and error threshold can be set to the same sufficiently large number. For manual testing items such as equipment size measurement and extreme environment tolerance, simply set the input value of the unit threshold statement to manual input, and the test threshold and error threshold can follow the judgment criteria of the automatic items. The centralized and summarized testing process is as follows: Figure 1 As shown: Assume the energy storage converter has m manual inspection items and n test items; manual inspection begins, with test flag values ​​of 0 and 1 representing pass / fail, directly outputting g. i The value of (x)(i=1,2,...,m) represents the final detection result of the manual part. Then, after testing all sub-test items, different values ​​of f are considered. j (x) will generate different experimental flag values ​​f j (x)(j=1,2,...,n), if f appears in it k If (x) = -1, then the kth test error is directly given, and the corresponding physical quantity needs to be retested; otherwise, take the AND of all flag values. If the final value is 1, it proves that the test passed; otherwise, it proves that the test failed. Finally, the test report will be given for the corresponding item results.

[0044] like Figure 1 The test architecture for manual (human) inspection and experimental inspection is shown. The entire architecture is divided into three parts: feature input, test process and database table.

[0045] The feature input section involves manual input or hardware scanning by a scanner to inject the required device detection feature information into the database, initializing the data stream of device information and test information.

[0046] The testing process will be entered into the data stream, with automatic and manual testing processes separated. Tests with detection values ​​outside the error threshold will be separately identified for retesting after debugging.

[0047] The data stream updated by the test process section, introduced by the feature entry section, will be synchronized with the database table section in real time. The update and synchronization of the data stream will be based on two basic dimensions: different levels of testing and different equipment types. Data streams updated at different times will be entered into the database table system in a certain order.

[0048] Multi-device type test architecture:

[0049] For testing processes of devices such as electrochemical energy storage batteries, a collaborative testing architecture involving multiple device types needs to be introduced. Electrochemical energy storage batteries require testing in three categories: individual cells, battery modules, and battery clusters. Each category differs in batch specifications, testing standards, and testing items. Based on this three-part testing architecture, the database tables need more detailed processing to handle the data flow interaction between multiple device types, testing levels, testing processes, and testing parameters.

[0050] The database tables include: test case database, platform project database, test procedure database, test equipment database, and registered equipment database.

[0051] The test procedure database and the test case database together constitute the test case layer, i.e., the data flow format of the testing experiment dimension. The test case database contains the call information for all test cases in the platform. It mainly records the test experiment ID, function call index, corresponding test level one and two, primary test name, and initialization parameters, test thresholds, and error thresholds for various test cases within the testing architecture. Using the test case database, various index information within the testing architecture can be accessed by linking to this database to obtain the corresponding test case information. It contains the data volume of all testing architecture test case indexes, and its part directly faces the backend test case calculation, i.e., the Python backend test case function implementation uses the corresponding test case for a given test.

[0052] The test procedure database is a standardized test process database for each test device. By referencing various electrochemical energy storage device test standards, the database tables and stores the test procedures from each standard in a hierarchical manner. At the information level, it belongs to the test case database and primarily records the test procedures applied to the corresponding type of device, including the names, IDs, indexes, and corresponding test sequences of the primary, first-level, and second-level test items for that device type. For example, in practical applications of energy storage batteries, the test procedure database is mainly used for default filling of process index data during device registration, thereby maximizing efficiency.

[0053] The registered device database is automatically generated for each device after registration. During registration, user-filled forms record device information for storage, primarily including device characteristic information such as device ID, model, and name. It also includes device test items (using test procedure database information by default based on device category). This characteristic information is used to proactively generate QR code and RFID device codes, as well as the corresponding QR code test item codes. Simultaneously, the registered device database also contains non-characteristic information, such as rated voltage, maximum operating voltage, rated power, and maximum power, used as data sources for automated testing processes.

[0054] The test equipment database is directly linked to the registered equipment database and also includes equipment registration statuses such as suspended, testing in progress, and testing completed, along with timestamps of status changes. Once a registered device's device code is scanned by the inventory machine, the device can be suspended within the testing architecture, and the suspended device will directly enter the test equipment database. The test equipment database is primarily used to link to the testing architecture project database, providing corresponding test information for ongoing experimental projects.

[0055] The platform project database is the core database of the platform's operational testing architecture and the primary source of data displayed on the platform's front end. It is linked to both the test equipment database and the test case database. The database mainly contains the test project IDs and indexes of test projects on suspended devices, as well as the corresponding test function indexes for each test case. It also includes the test status of the test projects, timestamps of test status changes, raw test data returned by the testing instruments, and test results analyzed by the test case functions.

[0056] As the database that directly connects to the platform's front end, the platform project database is downstream of all other databases. It stores the most timely test information and acts as an interface in database construction, modularizing the testing platform's functionality. This architecture is built on a MySQL database and stores data locally. When porting to other devices is required, database migration can be achieved through the SQLAlchemy module. This enables easy migration of global database files such as test procedure databases, facilitating the instantiation and execution of test processes on different terminal devices.

[0057] Figure 3 This demonstrates how data flows are represented in the platform's project database. Different types of projects are distinguished by different test IDs, while other content is linked to either the device-level database or the test project-level database. During communication with the backend, the data flow of the test cases uses JSON format for the dataset portion, stored as a dictionary.

[0058] Compatible with front-end interfaces:

[0059] The backend architecture reads upstream databases through interconnected model types, enabling direct calls from downstream databases to upstream databases, facilitating modular and streamlined platform development. Databases are centrally processed in the backend files responsible for routing, transforming them into easily formatted data formats or performing more detailed backend processing, ultimately awaiting further calls from the frontend Flask architecture in the form of database tables and dictionary lists.

[0060] The communication interface between the database and the front end can utilize relevant functions from the Flask architecture. In the corresponding route file, the functions to be called and the data variables required for each web application can be implemented using this architecture.

[0061] In the backend routing file, the processed data file is reorganized into a table-style variable, which is then directly linked to the webpage route corresponding to the generated WebApp, thereby realizing the connection between backend data and frontend display page.

[0062] When data is retrieved from the backend to the frontend, the frontend HTML file can use the Jinja2 language environment to access variables transmitted from the backend. Due to its strong compatibility with frontend JavaScript, variable retrieval and script writing on the frontend page are compatible and interoperable with JavaScript and CSS libraries, enabling the display of complex logic on the frontend interface.

[0063] For example, the classification rules for the three testing states, the classification of testing items for different devices and testing indexes, and the hierarchical display of sub-tests on the testing test page can all be implemented using Jinja2 and JavaScript. Figure 4 , Figure 5 The example manual experiment interface and its corresponding backend MySQL database are shown.

[0064] Automatic report generation architecture:

[0065] After the automated testing process is completed, the test data is automatically stored in a MySQL database. A program using the Python Flask framework connects to the database, and a web template for generating reports based on the test items and results is integrated into this program. Each time a device is tested in the system, the test results are processed, the device performance is rated, and the rating results, along with the device specification data, are added to the web template to generate an HTML webpage document. The final output is in PDF format. Generally, the report presents three parts: an overall performance rating of the tested device, a record of the device's technical specifications, and an evaluation of the specific test items. A sample evaluation table format is shown below. Figure 6 As shown.

[0066] The first part evaluates the overall performance level of the tested equipment. Basic information about the equipment, such as name, model, specifications, and manufacturer, is displayed. Test results are compared with national and industry standards, and performance is evaluated according to A, B, C, and D levels. The overall performance level and functional performance levels of the tested equipment are given according to certain standards, facilitating a more comprehensive consideration of the test results and operational performance. Information such as the testing unit, testing standards, and testing date are also included in this first part.

[0067] The technical specifications data of the equipment are recorded. This section records and displays the technical specifications data of the equipment, such as rated charging hours, nominal voltage, equipment size, mass, maximum voltage, current, and temperature. The recorded data is presented in tabular form with units indicated, so that users can have a clear understanding of the overall condition of the equipment, its usage conditions, and its working environment.

[0068] The evaluation of specific equipment testing items requires providing specific technical indicators for the tested items, as well as the detected technical performance data and grades. This information is presented in tabular form. Specific technical indicators include quantifiable indicators that can be represented by data, such as deviations in technical specification data, energy efficiency range, and charging energy recovery rate, as well as non-quantifiable indicators such as overcharge tests, drop tests, and heating tests. If specific quantitative data is available, it will be displayed; otherwise, it will be shown as whether the indicators are met or not. Performance grades are given based on the technical performance data and are evaluated using A, B, C, and D grades.

[0069] The above description is merely an embodiment of the present invention and does not limit the patent scope of the present invention. Any equivalent structural or procedural transformations made based on the content of the present invention's specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent protection scope of the present invention.

Claims

1. An automatic detection and report generation architecture for electrochemical energy storage devices based on data flow, characterized in that: include: Automatic detection architecture: It includes a feature input section, a test process section, and a database table section; The feature input section is used to inject the required device detection feature information into the database table section; The test process section describes all detections using unit threshold conditional statements: in, ; Indicates the first The test indicator values ​​of the sub-test items, This represents the value of the physical quantity ultimately detected in a certain test project. If this value is within the test threshold... and test threshold The value between these values ​​indicates that the device has passed the test for this item; if the value is between the test threshold, it means the device has passed the test. and error threshold Between or the physical quantity is between the error threshold and test threshold If the value is between 0 and 1, it means the test has failed; if the physical quantity is greater than the error threshold... Or less than the error threshold If the result is negative, it indicates that there is an error in the test and the test should be rescheduled. The test results are obtained by taking the AND operation of the test flag values ​​of all sub-test items; Automatic report generation architecture: Generates evaluation reports based on test results; The feature input section includes a part that injects the required device detection feature information into the database table by manual input or hardware scanning by a scanner, and initializes the data stream of device information and test information. The test process section separates the automatic detection process and the manual detection process in the input data stream, and also separates the tests where the detection quantity is outside the error threshold for retesting after debugging. The data streams introduced by the feature entry section and updated by the test process section will be synchronized with the database table section in real time. The update and synchronization of the data streams will be based on two fundamental dimensions: different levels of testing and different equipment types. Data streams updated at different times will be entered into the database table system in a certain order.

2. The automatic detection and report generation architecture for electrochemical energy storage devices based on data flow as described in claim 1, characterized in that: The database tables include a test case database, a platform project database, a test procedure database, a test equipment database, and a registered equipment database.

3. The automatic detection and report generation architecture for electrochemical energy storage devices based on data flow as described in claim 2, characterized in that: The test case database contains call information for all cases in the platform. Information on the corresponding test cases can be obtained by linking to the external test case database. It includes the data volume of all detection architecture case indexes.

4. The automatic detection and report generation architecture for electrochemical energy storage devices based on data flow as described in claim 2, characterized in that: The registered device database is automatically generated for each device after the registration process is completed; it includes the device's characteristic information and non-characteristic information, and is used as a data source for the automated testing process.

5. The automatic detection and report generation architecture for electrochemical energy storage devices based on data flow as described in claim 2, characterized in that: The test equipment database is directly linked to the registered equipment database and is used to link to the platform project database to provide corresponding test information for the experimental projects being tested.

6. The automatic detection and report generation architecture for electrochemical energy storage devices based on data flow as described in claim 2, characterized in that: The platform project database is used to display data on the platform front end, and it is also linked to the test equipment database and the test case database.

Images