Production line test data analysis method, system, equipment and program product

Abstract

The invention is suitable for the technical field of production data analysis, and provides a production line test data analysis method, system and device and a program product, and the method comprises the steps: obtaining a plurality of test result value sets corresponding to a plurality of test step identifiers; for each test step identifier, filling a test result value set corresponding to the test step identifier into a template file preset with a calculation formula for calculating a statistical index representing the characteristics of the production process, and triggering a calculation function of the template file to obtain the statistical index corresponding to the test step identifier; and on the basis of the template file which is filled with the test result value set and completes calculation, a single-step analysis file containing the statistical index is generated for each test step identifier, so that the flexibility of the system and the adaptability to service changes are improved, and the accuracy of a statistical analysis result is ensured.

Description

Technical Field

[0001] This application belongs to the field of production data analysis technology, and in particular relates to a method, system, equipment and program product for analyzing production line test data. Background Technology

[0002] In industrial production, to monitor and improve product quality, various testing steps on the production line generate massive amounts of test data, which are typically stored in a scattered manner in the form of spreadsheets. To assess the stability and capability of the production process, statistical analysis of this data is required to calculate key indicators such as process capability index and process accuracy index.

[0003] Currently, some statistical process control systems exist that can automatically collect and analyze production data. These systems can aggregate data from data sources and use built-in analytical functions to calculate relevant parameters. However, in these existing systems, the analytical functions and calculation logic are usually hard-coded in the background, and their statistical models and calculation logic are fixed. When production line engineers or quality management personnel want to adjust the calculation formulas, add new statistical indicators, or modify the report format according to actual needs, they must rely on software developers to modify, compile, and redeploy the core program. This process is complex, slow, and costly. Summary of the Invention

[0004] This application provides a method, system, equipment, and program product for analyzing test data on a production line, which can solve the technical problems of rigid calculation logic, poor flexibility, and poor scalability in existing automated analysis systems.

[0005] In a first aspect, embodiments of this application provide a method for analyzing production line test data, including: Obtain a set of multiple test result values ​​corresponding to multiple test step identifiers; For each test step identifier, the set of test result values ​​corresponding to it is filled into a template file with a pre-set calculation formula for calculating statistical indicators that characterize the production process characteristics, and the calculation function of the template file is triggered to obtain the statistical indicators corresponding to the test step identifier. Based on the template file containing the populated set of test result values ​​and completed calculations, a single-step analysis file with statistical indicators is generated for each test step identifier.

[0006] In one possible implementation of the first aspect, obtaining a set of multiple test result values ​​corresponding to multiple test step identifiers includes: Receive the source data path used to define the range of multiple raw test files to be processed; Traverse multiple original test files within the source data path, and for each original test file, parse it according to the preset description information to identify the test step identifier and the corresponding test result value contained in the original test file; The test result values ​​identified from all the original test files are aggregated according to their respective test step identifiers, forming a corresponding set of test result values ​​for each unique test step identifier.

[0007] In one possible implementation of the first aspect, the traversal of multiple original test files within the source data path is further included before: Based on the obtained date range, multiple original test files under the source data path are filtered, and only the original test files with dates within the date range are subjected to subsequent parsing and aggregation steps.

[0008] In one possible implementation of the first aspect, the statistical indicator includes one or more of the following: process capability index, process accuracy index, process potential index, maximum value, minimum value, average value, or standard deviation.

[0009] In one possible implementation of the first aspect, the method further includes: Extract the statistical indicators of all test step identifiers and generate a multi-step summary report containing all test step identifiers and their corresponding statistical indicators.

[0010] In one possible implementation of the first aspect, the method further includes: Receive a target path, which serves as the root directory for storing all analysis results; In the root directory, create an analysis session folder named after the current execution timestamp; For each test step identifier, create a step folder named after that test step identifier within the analysis session folder to store the single step analysis files associated with that test step identifier; wherein, an analysis session folder includes at least one step folder named after a test step identifier.

[0011] In one possible implementation of the first aspect, the work step folder also contains at least one of the following files: A data traceability file; wherein the data traceability file records each test result value that constitutes the set of test result values ​​and the original test file name from which it originates; The single-step analysis file; A visualization chart file generated from the set of test result values.

[0012] In one possible implementation of the first aspect, the method further includes: When a new test step identifier is received and an existing analysis session folder is specified as the target, the following incremental update steps are performed: Check if a step folder corresponding to the new test step identifier exists in the existing analysis session folder; If it is determined that the new test step identifier does not exist, a step folder is created within the analysis session folder, and its corresponding single-step analysis file is generated; and, Update the multi-step summary report in the analysis session folder to add the new test step identifier and its corresponding statistical indicators to the multi-step summary report.

[0013] Secondly, embodiments of this application provide a production line test data analysis system, including: The acquisition module is used to acquire a set of multiple test result values ​​corresponding to multiple test step identifiers; The statistical indicator calculation module is used to fill the set of test result values ​​corresponding to each test step identifier into a template file with a pre-set calculation formula for calculating statistical indicators that characterize the production process characteristics, and trigger the calculation function of the template file to obtain the statistical indicator corresponding to the test step identifier. The generation module is used to generate a single-step analysis file containing statistical indicators for each test step identifier, based on a template file that has been populated with test result values ​​and completed calculations.

[0014] Thirdly, embodiments of this application provide a computer 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 production line test data analysis method described in any one of the first aspects above.

[0015] Fourthly, embodiments of this application provide a computer-readable storage medium storing a computer program that, when executed by a processor, implements the production line test data analysis method described in any one of the first aspects above.

[0016] Fifthly, embodiments of this application provide a computer program product that, when run on a computer device, causes the computer device to execute the production line test data analysis method described in any one of the first aspects.

[0017] In this embodiment, multiple sets of test result values ​​corresponding to multiple test step identifiers are obtained. For each test step identifier, the set of test result values ​​corresponding to it is filled into a template file containing a pre-set calculation formula for calculating statistical indicators characterizing the production process. The calculation function of the template file is then triggered to obtain the statistical indicator corresponding to the test step identifier. Based on the template file with the filled test result value set and completed calculation, a single-step analysis file containing statistical indicators is generated for each test step identifier. Unlike the hard-coded calculation logic in existing technologies, placing the calculation logic in an external template file allows non-programmers to directly modify the formulas in the template file, easily customizing or extending the statistical indicators, thus improving the system's flexibility and adaptability to business changes. Furthermore, the fully automated data processing workflow avoids errors that may occur during manual operation, ensuring the accuracy of the statistical analysis results.

[0018] It is understood that the beneficial effects of the second to fifth aspects mentioned above can be found in the relevant descriptions in the first aspect mentioned above, and will not be repeated here. Attached Figure Description

[0019] To more clearly illustrate the technical solutions in the embodiments of this application, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0020] Figure 1 This is a schematic flowchart of a production line test data analysis method provided in an embodiment of this application; Figure 2 This is a schematic diagram of the file structure of an analysis result provided in an embodiment of this application; Figure 3 This is a schematic diagram of the structure of the production line test data analysis system provided in the embodiments of this application; Figure 4 This is a schematic diagram of the structure of the computer device provided in the embodiments of this application. Detailed Implementation

[0021] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application may also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted so as not to obscure the description of this application with unnecessary detail.

[0022] It should be understood that, when used in this application specification and the appended claims, the term "comprising" indicates the presence of the described features, integrals, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or a collection thereof.

[0023] It should also be understood that the term “and / or” as used in this application specification and the appended claims means any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.

[0024] As used in this application specification and the appended claims, the term "if" may be interpreted, depending on the context, as "when," "once," "in response to determination," or "in response to detection." Similarly, the phrase "if determined" or "if detected [the described condition or event]" may be interpreted, depending on the context, as meaning "once determined," "in response to determination," "once detected [the described condition or event]," or "in response to detection [the described condition or event]."

[0025] Furthermore, in the description of this application and the appended claims, the terms "first," "second," "third," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0026] References to "one embodiment" or "some embodiments" as described in this specification mean that one or more embodiments of this application include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized.

[0027] This application provides a method for analyzing test data on a production line. In a specific application scenario, this method can be applied to manufacturing production lines for complex electronic products such as smartphones, tablets, automotive electronic control units (ECUs), or home appliances. On such large-scale production lines, the data is characterized by massive volume, high speed, and diversity: each product coming off the line must undergo dozens or even hundreds of automated testing processes, generating tens of thousands of raw test files daily. These testing processes can be collectively referred to as test steps in this application, such as battery capacity testing, screen brightness uniformity testing, camera focus speed testing, or wireless network connection strength testing. It is understood that each test step can be executed by specialized test equipment (ATE) and generate one or more raw test files recording the test results. These files may have various formats, including but not limited to comma-separated value (CSV) files, tab-separated value (TSV) files, Microsoft Excel spreadsheets (.xls, .xlsx) files, or even custom text or XML format files. Furthermore, these files are usually stored in different directories on a file server, and their organizational structure may vary depending on the production line, shift, or equipment number. The method provided in this embodiment aims to automate the processing of such massive, heterogeneous raw test data in order to achieve efficient, flexible, and traceable evaluation of the quality characteristics of the production process.

[0028] Please see Figure 1 , Figure 1 A schematic flowchart of a production line test data analysis method provided in an embodiment of this application is shown.

[0029] S101, obtain a set of multiple test result values ​​corresponding to multiple test step identifiers.

[0030] Among them, the test step identifier is a unique identifier used to distinguish different test steps on the production line (such as battery capacity test, screen brightness test, and camera focus speed test). It is the core basis for classifying and aggregating the original test data, ensuring that data from the same test step are grouped into one category.

[0031] Test result value set: For a specific test step identifier, the set of all test result values ​​extracted and aggregated from all original test files (such as [4501.2,4499.8,4505.1,…] for battery capacity test) is the direct data source for calculating statistical indicators.

[0032] In this embodiment of the application, the test data is categorized according to the test step identifier from the original test files stored in a scattered manner on the production line through filtering, parsing and aggregation operations, forming a set of structured test result values ​​corresponding to each identifier, providing a regular data source for subsequent calculation of statistical indicators.

[0033] Optionally, S101 obtains a set of multiple test result values ​​corresponding to multiple test step identifiers, specifically including: Step a1: Receive the source data path used to define the range of multiple raw test files to be processed.

[0034] Among them, the original test files are files that record test data generated by each test step on the production line.

[0035] Source data path: This path defines the storage range of the multiple raw test files to be processed. Its purpose is to specify where the system should read the raw test files from. The source data path can be a local folder path, a network shared folder path, or a cloud storage service path.

[0036] In this embodiment of the application, a source data path input by an operator through a user interface can be received to define the scope of multiple original test files to be processed.

[0037] As an optional implementation, filtering can be performed before formally traversing and parsing the files. Specifically: based on the obtained date range, multiple original test files under the source data path are filtered, and only the original test files whose dates fall within the date range are subjected to subsequent parsing and aggregation steps.

[0038] In this embodiment, the system receives a user-input date range (such as a start date and an end date) or time range (accurate to the hour, minute, and second). When traversing files under the specified source data path, the system checks the metadata information of each file (especially the file's last modification date or creation date) and compares the file's date with the user-defined date range. Only files whose dates fall within this range are considered valid files to be processed and added to the list of files to be processed. This effectively limits the analysis scope to a specific time period (e.g., analyzing production data from the previous shift or investigating quality issues occurring on a specific date), avoiding the processing of irrelevant historical data, thereby improving processing efficiency and the relevance of the analysis.

[0039] Step a2: Traverse multiple original test files within the source data path. For each original test file, parse it according to the preset description information to identify the test step identifier and the corresponding test result value contained in the original test file.

[0040] The pre-defined description information is a set of rules that tells the system how to extract key information from structured or semi-structured files; it can also be called a data mapping configuration file. This configuration file can be stored in an easily editable format (such as JSON, YAML, or XML). For example, for a raw test file in comma-separated value format, the description information could define the test step identifier as being located in column 3 of the file (column index 2, or column name Test_Item), and the test result value as being located in column 8 of the file (column index 7, or column name Measurement_Value). For spreadsheet format files, the description information could define the test step identifier as being in column B of a worksheet named Summary, and the test result value as being in column F of the same worksheet. This description information can be pre-configured and stored in the configuration file for the system to dynamically load when parsing different file types. This design allows users to modify only the configuration file when the test file format changes, without altering the main program code, greatly enhancing the system's adaptability and maintainability.

[0041] In this embodiment, after determining the list of original test files to be processed, the files in this list are traversed one by one. For each original test file, it is necessary to parse it according to preset description information in order to accurately identify the test step identifiers contained in the file and their corresponding test result values.

[0042] The process involves opening and reading the contents of each raw test file based on the loaded description information. During the reading process, an error handling mechanism can be implemented. For example, if the data format of a line does not conform to expectations (such as non-numeric characters appearing in the test result value column), the error information (including the filename and line number) can be recorded in a log file, and that line can be skipped, continuing to process the rest of the file, thus ensuring the robustness of the entire data acquisition process. For each valid data entry, the test step identifier (such as the string "battery capacity test") and the test result value (such as the value 4501.2) are extracted.

[0043] Step a3 involves aggregating the test result values ​​identified from all the original test files according to their respective test step identifiers, forming a corresponding set of test result values ​​for each unique test step identifier.

[0044] In this embodiment of the application, the test result values ​​identified from all the original test files need to be aggregated according to the test step identifiers to which they belong, so as to form a corresponding set of test result values ​​for each unique test step identifier.

[0045] Understandably, to efficiently complete this aggregation process, a key-value data structure, such as a dictionary or hash map, can be maintained in computer memory. The key of this data structure is a test step identifier string, while the value is a dynamic array or list storing all test result values ​​corresponding to that step identifier. During file traversal, whenever a data pair is parsed (e.g., battery capacity test, 4501.2), it is checked whether an entry with "battery capacity test" as the key already exists in the data structure. If it exists, the value 4501.2 is appended to its corresponding list; if it does not exist, a new entry with "battery capacity test" as the key is created, and its corresponding value is a new list containing only 4501.2. Once all original test files have been traversed and parsed, the data structure will completely store all test step identifiers involved in this analysis task, as well as a set of all test result values ​​corresponding to each identifier. For example: {Battery capacity test: [4501.2,4499.8,4505.1,…], Screen brightness test: [501.3,502.1,499.9,…],…}. At this point, step S101 is complete, and the original, scattered data has been transformed into structured, step-based memory objects.

[0046] S102, for each test step identifier, the set of test result values ​​corresponding to it is filled into a template file with a pre-set calculation formula for calculating statistical indicators characterizing the production process characteristics, and the calculation function of the template file is triggered to obtain the statistical indicators corresponding to the test step identifier.

[0047] A template file is a pre-made file containing data placeholders and calculation logic. In this embodiment, the template file can be a spreadsheet file (such as a file with the extension .xlsx or .xlsm), for example, CPK_Template.xlsx. Within this template file, specific areas can be pre-defined as data input areas, such as column A, for subsequent programmatically filling in test result values; while other cells contain pre-defined formulas for calculations. This template file essentially functions as a reusable calculation engine.

[0048] The calculation formulas are used to calculate statistical indicators characterizing the production process. As an optional implementation, these statistical indicators may include one or more commonly used indicators in the field of Statistical Process Control (SPC), such as: process capability index (Cpk, measuring process performance within specification limits), process accuracy index (Ca, measuring the deviation of the process mean from the specification center), process potential index (Cp, measuring the dispersion of the process), maximum value, minimum value, mean, and standard deviation. The calculation formulas for these indicators are pre-written into specific cells of the template file. For example, cell B1 can contain the formula =MAX(A:A) to calculate the maximum value, cell B2 can contain the formula =MIN(A:A) to calculate the minimum value, cell B3 can contain the formula =AVERAGE(A:A) to calculate the mean, and cell B4 can contain the formula =STDEV.S(A:A) to calculate the sample standard deviation. For more complex indicators such as the process capability index, the calculation formula may need to reference the upper specification limit (USL) and lower specification limit (LSL) of the product. These specification values ​​can be preset in other cells of the template file (such as C1 and C2), or written by the program when filling in the data. A process capability index calculation formula can be =MIN((C1-B3) / (3*B4), (B3-C2) / (3*B4)).

[0049] It is important to emphasize that, since these formulas are not hard-coded into the program code, this template file can be opened at any time, and any formula can be modified, deleted, or added directly using the functions of spreadsheet software according to the latest quality standards and analysis needs, without the need for software development or recompilation and deployment. This gives the system a high degree of flexibility.

[0050] In an optional embodiment, during execution of S102, each test step identifier aggregated in S101 is traversed. Taking battery capacity testing as an example, the system performs the following operations: First, a CPK_Template.xlsx template file is programmatically copied into the file system to form a temporary copy (e.g., named temp_file_123.xlsx); then, the system uses a programmatic interface (e.g., using third-party libraries such as Apache POI or OpenPyXML to manipulate the spreadsheet file; the entire process can be executed in a headless mode on the server background, i.e., without displaying a graphical user interface) to write the set of test result values ​​corresponding to the battery capacity test (i.e., the list of values ​​[4501.2, 4499.8, 4505.1, ...]) in memory row by row into column A of the temporary copy file. After the data is populated, the system instructs the spreadsheet library to recalculate all formulas in the workbook, or, when saving the file, utilizes the features supported by the spreadsheet file format itself to ensure that the formulas are automatically evaluated. Because the spreadsheet's built-in calculation engine automatically calculates the newly filled data in column A based on preset formulas in cells B1 to B4 when the file is saved or triggered by a command, and updates the results to these cells, the temporary copy file contains the original data in column A and the latest statistical indicators calculated from this data for columns B and other areas. This fill-and-trigger calculation method obtains the corresponding statistical indicators for the battery capacity testing step. The system repeats this process for each test step, generating a temporary file containing its calculation results for each step.

[0051] S103, based on the template file that has been filled with test result value set and completed calculation, generates a single-step analysis file containing statistical indicators for each test step identifier.

[0052] This step essentially involves the solidification, naming, and structured storage of the product from S102. In S102, once a temporary copy file is populated with data and calculations are completed, it constitutes a complete file containing the original data and analysis results. Therefore, this step involves storing the temporary copy file. For example, for battery capacity testing, the processed temporary copy file can be renamed to Battery Capacity Test_CPK Analysis Report.xlsx, which is the single-step analysis file referred to in this application's embodiments.

[0053] In this embodiment, multiple sets of test result values ​​corresponding to multiple test step identifiers are obtained. For each test step identifier, the set of test result values ​​corresponding to it is filled into a template file containing a pre-set calculation formula for calculating statistical indicators characterizing the production process. The calculation function of the template file is then triggered to obtain the statistical indicator corresponding to the test step identifier. Based on the template file with the filled test result value set and completed calculation, a single-step analysis file containing statistical indicators is generated for each test step identifier. Unlike the hard-coded calculation logic in existing technologies, placing the calculation logic in an external template file allows non-programmers to directly modify the formulas in the template file, easily customizing or expanding the statistical indicators, thus improving the system's flexibility and adaptability to business changes. Furthermore, the fully automated data processing avoids errors that may occur during manual operation, ensuring the accuracy of the statistical analysis results.

[0054] In one optional embodiment, to better organize and manage the generated analysis results, a series of file and folder creation operations are performed to form a clear, self-contained analysis report package. Specifically, this includes: receiving a target path, which serves as the root directory for storing all analysis results; creating an analysis session folder named after the current execution timestamp within the root directory; for each test step identifier, creating a step folder named after that test step identifier within the analysis session folder to store the single-step analysis files associated with that test step identifier; wherein, an analysis session folder includes at least one step folder named after a test step identifier.

[0055] In the embodiments of this application, please refer to Figure 2This diagram illustrates a file structure diagram of analysis results provided by an embodiment of this application. Specifically, it first receives a target path, which is a user-specified root directory for storing all analysis results. To isolate the results of each independent analysis task, the system can create an analysis session folder named with the current execution timestamp or a user-defined name in this root directory, for example: 20240601103000_DailyReport. Subsequently, for each test step identifier to be analyzed, a step folder named with that test step identifier is created inside the aforementioned analysis session folder, for example, a battery capacity test folder and a screen brightness test folder. An analysis session folder can contain at least one such step folder. Finally, the single-step analysis file generated for the battery capacity test in S103 (i.e., battery capacity test_CPK analysis report.xlsx) will be moved and stored in the path D:\20240601103000_DailyReport. In this way, the analysis results of each test step are stored independently in their own folder, with a clear structure that makes it easy for users to find, view, archive, and share.

[0056] As an optional implementation, to further enrich the analysis results, the process step folder also contains at least one of the following files: A data traceability file; wherein the data traceability file records each test result value that constitutes the set of test result values ​​and the original test file name from which it originates; The single-step analysis file; A visualization chart file generated from the set of test result values.

[0057] In the embodiments of this application, in addition to storing single-step analysis files, each work step folder may also store at least one of the following: data traceability files or visualization chart files.

[0058] The data traceability file records the specific source of each data point that constitutes the set of test result values ​​for this step, facilitating root cause analysis when abnormal data is discovered. To generate this file, during the parsing of the original test file in S101, in addition to extracting the test result values, the filename, line number, and optional product serial number of the original value must also be recorded. Taking the battery capacity test step as an example, during the report generation stage, a file named "data source traceability.csv" can be created for the battery capacity test step. Its content can include the test result values ​​and their source information, such as: 4501.2,file_A.csv,line 15,SN001, 4499.8,file_B.csv,line 32,SN002, etc.

[0059] Among them, the visualization chart files present the numerical test result sets in a graphical way, making the data distribution and trends more intuitive. For example, the system can call chart generation libraries (such as Matplotlib, Plotly, etc.), take the battery capacity test result set as input, generate histograms, box plots, or control charts of the data, and save them as image files (such as .png) or interactive web page files (such as .html) in the corresponding process step folder.

[0060] In an optional embodiment, to provide an overview of all steps in this analysis task, the method may further include a step of generating a multi-step summary report. Specifically, after all single-step analysis files are generated, statistical indicators of all test step identifiers are extracted to generate a multi-step summary report containing all test step identifiers and their corresponding statistical indicators. For example, a statistical summary report.csv or Summary.xlsx file can be created in the root directory of the analysis session folder. The system will traverse each step folder, open the single-step analysis files within, and read the statistical indicator values ​​(such as Cpk, Cp, average, etc.) from predetermined cells in read-only mode. Then, the name of the step along with the read indicator value is written as a new row to the summary report. After all steps are processed, the summary report forms a clear table, with each row representing a test step and each column representing a key statistical indicator. This allows managers to quickly identify which steps have low process capabilities or anomalies, thereby achieving a comprehensive monitoring of the quality status of the entire production process.

[0061] Optionally, in the step of generating a multi-step summary report, the statistical indicators included in the multi-step summary report can be flexibly configured according to the actual production quality monitoring needs. It can select all of the statistical indicators that characterize the production process, such as process capability index, process accuracy index, process potential index, maximum value, minimum value, average value, and standard deviation, or select a subset of them. By accurately matching the analysis focus in the specific application scenario, the summary report can not only comprehensively cover the key quality assessment dimensions, but also avoid redundant information interference, helping to focus on core data and efficiently control the overall production process quality status.

[0062] It should be noted that the template files in the above embodiments are not limited to a specific spreadsheet file format. Their core purpose is to provide a mechanism that pre-configures calculation logic and receives data to generate results, thereby decoupling data from calculation logic. In an optional embodiment, an alternative implementation based on Extensible Markup Language (XML) and Extensible Stylesheet Language Transformation (XSLT) technologies will be demonstrated, which can achieve the same objective.

[0063] In this embodiment, the data acquisition and aggregation steps (corresponding to S101 above) remain unchanged, and multiple test result value sets corresponding to multiple test step identifiers are also aggregated from the original test file. The main difference lies in the subsequent calculation and generation steps.

[0064] Here, the template file is no longer a spreadsheet file, but a pre-built file written using XSLT, such as report_template.xslt. XSLT is a language used to transform XML documents into another type of document (such as HTML, plain text, or other XML), and it has excellent data processing and mathematical operation capabilities. For example, it can use built-in XPath functions (such as sum(), count(), max(), min(), etc.) to calculate statistical indicators such as average, maximum, and minimum values ​​by combining these functions. Complex formulas, such as standard deviation or Cpk, can also be implemented through features such as variables, template rules, and recursive templates.

[0065] The specific work process is as follows: In step b1, after the data aggregation is completed, for each test step identifier (e.g., camera focus speed test), instead of copying and filling the spreadsheet file, a temporary, structured plain data XML file is dynamically generated from the set of test result values ​​corresponding to that step in memory (e.g., [10.1, 10.2, 9.9, ...], in milliseconds).

[0066] Step b2: Invoke a standard XSLT processor, passing the pre-built report_template.xslt template file and the temporary data XML file generated in the previous step as input to the processor.

[0067] In step b3, the XSLT processor parses the template file and processes the data file according to the rules defined therein. For example, the template may define the following logic: use count( / / item) to calculate the total number of data points, use sum( / / value) to calculate the sum of all values, and then use sum( / / value) div count( / / item) to calculate the average.

[0068] Step b4: After the XSLT processor completes its execution, its output is a formatted file, such as an HTML webpage. This file contains all the calculated statistical metrics and has a well-formatted layout, allowing users to open and view it using a standard web browser without any specific software. The output can also be a plain text file, a CSV file, or another XML format to meet the needs of different downstream systems.

[0069] This embodiment, by combining XML and XSLT, also achieves effective separation of data (in the XML data file) and computational logic (in the XSLT template file). When it is necessary to modify the calculation method of statistical indicators or the presentation format of the report, only the report_template.xslt template file needs to be modified, without changing the main program code. At the same time, the generated HTML report has excellent cross-platform compatibility. Therefore, any mechanism that can predefine computational logic and receive external data to generate the final result can be considered a specific implementation of the template file disclosed in this application.

[0070] In an optional embodiment, the method further includes: when a new test step identifier is received and an existing analysis session folder is specified as the target, performing the following incremental update steps: checking whether a step folder corresponding to the new test step identifier exists in the existing analysis session folder; if it is determined that it does not exist, creating a step folder for the new test step identifier in the analysis session folder and generating its corresponding single-step analysis file; and updating the multi-step summary report under the analysis session folder to add the new test step identifier and its corresponding statistical indicators to the multi-step summary report.

[0071] To facilitate understanding, an example is given here. Suppose that at a certain time (e.g., 10:00 AM every day), a complete analysis task has been completed according to the method described in the above embodiment, and a corresponding analysis session folder (e.g., 20240601103000) has been generated, which contains the step folders of all test steps at that time, single step analysis files, and a multi-step summary report.

[0072] After a period of time (e.g., by 6 PM), the production line resumes operation and generates a new batch of raw test files. These new files may contain new data from existing test steps (e.g., battery capacity testing), or they may represent entirely new test steps due to the introduction of new equipment or processes, such as system response time testing. At this point, the goal is to add the analysis results of this new step to the existing analysis session without re-analyzing all historical data. Specifically, this includes: Step c1: Receive incremental update requests.

[0073] Specifically, when the analysis program is run again, the source data path is set to the directory where the newly generated raw test files are stored, and the target path is specified as the existing analysis session folder path, i.e., D:\20240601103000. When the specified target path is detected to be an existing analysis session folder that conforms to its naming rules, the incremental update process is automatically triggered. At the same time, when aggregating data from the new raw test files, the new test step identifier (system response time test) and the existing step identifier (battery capacity test) are identified.

[0074] Step c2: Determine if the work step folder exists.

[0075] For each test step identified from the new data, a check must be performed within the target analysis session folder. For the new step identifier "System Response Time Test," the system checks if a subfolder named "System Response Time Test" exists under the path D:\20240601103000. Since this is the first occurrence, the check result is negative. For existing steps such as "Battery Capacity Test" that also appear in the new data, the same check is performed, and it is found that the corresponding step folder already exists, so the result is positive.

[0076] Step c3: If the judgment result is yes, it indicates that the analysis result of this step already exists in the current analysis session. In this mode, all subsequent processing for this step will be skipped, thus avoiding duplicate calculations and file overwriting. This judgment and skipping mechanism strictly limits the computation to the newly added parts, saving computing resources and time.

[0077] Step c4: If the judgment result is negative, create a new step's analysis result.

[0078] Since the system response time test step folder does not exist, the system will only perform a complete analysis and generation process similar to that described in the above embodiments for this new step, specifically including: creating a new step folder named "System Response Time Test" under the path D:\20240601103000; filling the template file with the aggregated system response time test result value set in memory and triggering the calculation; generating the corresponding single-step analysis file based on the calculated template file and storing it in the newly created step folder; optionally, generating a data traceability file and a visualization chart file at the same time and storing them together in the step folder.

[0079] Step c5: Update the multi-step summary report.

[0080] In this embodiment, after generating corresponding analysis results for all newly emerging steps, the process proceeds to step c5, updating the multi-step summary report. To maintain the integrity and timeliness of the summary report, the multi-step summary report (e.g., statistical summary report.csv) located at D:\20240601103000 is opened in read-write mode. All existing content is read, and then one or more new lines of data are appended to the end of the file. In this example, the core statistical indicators calculated for the system response time test in step c4, along with their step names, are formatted as a new line and appended to the end of the file. Finally, the system saves and closes the summary report file. In an optional implementation, the entire report content can be sorted by step name after appending to maintain the report's order.

[0081] This concludes the incremental update process. Ultimately, the original analysis session folder 20240601103000 now contains a new folder for the system response time test and its complete set of analysis files. The overall summary report is also updated, while all existing step analysis results remain unchanged. This incremental update mechanism allows this method to efficiently adapt to ongoing production processes, maintaining the historical continuity of analysis results while saving computational resources and time.

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

[0083] Corresponding to the production line test data analysis method described in the above embodiments, Figure 3 The diagram shows a structural block diagram of the production line test data analysis system provided in the embodiments of this application. For ease of explanation, only the parts related to the embodiments of this application are shown.

[0084] Reference Figure 3 The production line test data analysis system includes: The acquisition module is used to acquire a set of multiple test result values ​​corresponding to multiple test step identifiers.

[0085] The statistical indicator calculation module is used to fill the set of test result values ​​corresponding to each test step identifier into a template file with a pre-set calculation formula for calculating statistical indicators that characterize the production process characteristics, and trigger the calculation function of the template file to obtain the statistical indicator corresponding to the test step identifier.

[0086] The generation module is used to generate a single-step analysis file containing statistical indicators for each test step identifier, based on a template file that has been populated with test result values ​​and completed calculations.

[0087] In one possible implementation, the production line test data analysis system also includes a user interface module. This module acts as a portal for interaction between the system and the user, receiving user input parameters required to execute the analysis task. These parameters may include: the source data path containing the original test files, the target path for storing the analysis results, an optional date range, the path to the configuration file used for data parsing, and the selection of whether to perform a full analysis or an incremental update. This module can be a graphical user interface (GUI), a command-line interface (CLI), or a web service interface (API).

[0088] In one possible implementation, the acquisition module is used for: Receive the source data path used to define the range of multiple raw test files to be processed; Traverse multiple original test files within the source data path, and for each original test file, parse it according to the preset description information to identify the test step identifier and the corresponding test result value contained in the original test file; The test result values ​​identified from all the original test files are aggregated according to their respective test step identifiers, forming a corresponding set of test result values ​​for each unique test step identifier.

[0089] In one possible implementation, the acquisition module is used for: Based on the obtained date range, multiple original test files under the source data path are filtered, and only the original test files with dates within the date range are subjected to subsequent parsing and aggregation steps.

[0090] In one possible implementation, the statistical indicators include one or more of the following: process capability index, process accuracy index, process potential index, maximum value, minimum value, mean value, or standard deviation.

[0091] In one possible implementation, the production line test data analysis system also includes a multi-step summary report generation module, which is used to extract statistical indicators of all test step identifiers and generate a multi-step summary report containing all test step identifiers and their corresponding statistical indicators.

[0092] In one possible implementation, the production line test data analysis system further includes a creation module for receiving a target path, which serves as the root directory for storing all analysis results; under the root directory, an analysis session folder named after the current execution timestamp is created; for each test step identifier, a step folder named after the test step identifier is created within the analysis session folder to store the single step analysis files associated with that test step identifier; wherein, an analysis session folder includes at least one step folder named after the test step identifier.

[0093] In one possible implementation, the work step folder also contains at least one of the following files: A data traceability file; wherein the data traceability file records each test result value that constitutes the set of test result values ​​and the original test file name from which it originates; The single-step analysis file; A visualization chart file generated from the set of test result values.

[0094] In one possible implementation, the production line test data analysis system further includes an incremental module, used to: check whether a step folder corresponding to the new test step identifier exists in the existing analysis session folder; if it is determined that it does not exist, create a step folder for the new test step identifier in the analysis session folder and generate its corresponding single step analysis file; and update the multi-step summary report under the analysis session folder to add the new test step identifier and its corresponding statistical indicators to the multi-step summary report.

[0095] It should be noted that the information interaction and execution process between the above modules are based on the same concept as the method embodiments of this application. For details on their specific functions and technical effects, please refer to the method embodiments section, which will not be repeated here.

[0096] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is merely an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiments can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit. Furthermore, the specific names of the functional units and modules are only for easy differentiation and are not intended to limit the scope of protection of this application. The specific working process of the units and modules in the above system can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0097] This application also provides a computer device, which includes: at least one processor, a memory, and a computer program stored in the memory and executable on the at least one processor, wherein the processor executes the computer program to implement the steps in any of the above method embodiments.

[0098] This application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps described in the various method embodiments above.

[0099] This application provides a computer program product that, when run on a computer device, enables the computer device to perform the steps described in the above-described method embodiments.

[0100] Figure 4 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application. Figure 4 As shown, the computer device of this embodiment includes: at least one processor 40 ( Figure 4 (Only one is shown in the diagram), memory 41, and computer program 42 stored in the memory 41 and executable on the at least one processor 40, wherein the processor 40 executes the computer program 42 to implement the steps in any of the above-described embodiments of the production line test data analysis method.

[0101] The computer device may include, but is not limited to, a processor 40 and a memory 41. Those skilled in the art will understand that... Figure 4The examples of computer devices are merely examples and do not constitute a limitation on computer devices. They may include more or fewer components than shown in the illustration, or combinations of certain components, or different components. For example, they may also include input / output devices, network access devices, etc.

[0102] The processor 40 may be a Central Processing Unit (CPU), or it may be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor may be a microprocessor or any conventional processor.

[0103] In some embodiments, the memory 41 may be an internal storage unit of the computer device, such as a hard disk or memory. In other embodiments, the memory 41 may be an external storage device of the computer device, such as a plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, etc. Furthermore, the memory 41 may include both internal and external storage units of the computer device. The memory 41 is used to store the operating system, applications, bootloader, data, and other programs, such as the program code of the computer program. The memory 41 can also be used to temporarily store data that has been output or will be output.

[0104] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, all or part of the processes in the methods of the above embodiments of this application can be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. The computer-readable medium can include at least: any entity or device capable of carrying computer program code to a device / computer equipment, a recording medium, a computer memory, a read-only memory (ROM), a random access memory (RAM), an electrical carrier signal, a telecommunication signal, and a software distribution medium. Examples include USB flash drives, portable hard drives, magnetic disks, or optical disks. Computer-readable media cannot be electrical carrier signals or telecommunication signals.

[0105] In the above embodiments, the descriptions of each embodiment have different focuses. For parts that are not described in detail or recorded in a certain embodiment, please refer to the relevant descriptions of other embodiments.

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

[0107] In the embodiments provided in this application, it should be understood that the disclosed apparatus / computer devices and methods can be implemented in other ways. For example, the apparatus / computer device embodiments described above are merely illustrative. For instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual couplings or direct couplings or communication connections may be through some interfaces; indirect couplings or communication connections between devices or units may be electrical, mechanical, or other forms.

[0108] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0109] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.

Claims

1. A method for analyzing test data from a production line, characterized in that, The method includes: Obtain a set of multiple test result values ​​corresponding to multiple test step identifiers; For each test step identifier, the set of test result values ​​corresponding to it is filled into a template file with a pre-set calculation formula for calculating statistical indicators that characterize the production process characteristics, and the calculation function of the template file is triggered to obtain the statistical indicators corresponding to the test step identifier. Based on the template file containing the populated set of test result values ​​and completed calculations, a single-step analysis file with statistical indicators is generated for each test step identifier.

2. The method according to claim 1, characterized in that, The process of obtaining a set of multiple test result values ​​corresponding to multiple test step identifiers includes: Receive the source data path used to define the range of multiple raw test files to be processed; The system iterates through multiple original test files within the source data path. For each original test file, it parses the data according to preset description information to identify the test step identifiers and corresponding test result values ​​contained in the original test file. The test result values ​​identified from all the original test files are aggregated according to their respective test step identifiers, forming a corresponding set of test result values ​​for each unique test step identifier.

3. The method according to claim 2, characterized in that, The step of traversing multiple original test files within the source data path also includes: Based on the obtained date range, multiple original test files under the source data path are filtered, and only the original test files with dates within the date range are subjected to subsequent parsing and aggregation steps.

4. The method according to claim 1, characterized in that, The statistical indicators include one or more of the following: process capability index, process accuracy index, process potential index, maximum value, minimum value, average value, or standard deviation.

5. The method according to claim 4, characterized in that, The method further includes: Extract the statistical indicators of all test step identifiers and generate a multi-step summary report containing all test step identifiers and their corresponding statistical indicators.

6. The method according to claim 5, characterized in that, The method further includes: Receive a target path, which serves as the root directory for storing all analysis results; In the root directory, create an analysis session folder named after the current execution timestamp; For each test step identifier, create a step folder named after that test step identifier within the analysis session folder to store the single step analysis files associated with that test step identifier; wherein, an analysis session folder includes at least one step folder named after a test step identifier.

7. The method according to claim 6, characterized in that, The process step folder also contains at least one of the following files: A data traceability file; wherein the data traceability file records each test result value that constitutes the set of test result values ​​and the original test file name from which it originates; The single-step analysis file; A visualization chart file generated from the set of test result values.

8. The method according to claim 6, characterized in that, The method further includes: When a new test step identifier is received and an existing analysis session folder is specified as the target, the following incremental update steps are performed: Check if a step folder corresponding to the new test step identifier exists in the existing analysis session folder; If it is determined that the new test step identifier does not exist, a step folder is created within the analysis session folder, and its corresponding single-step analysis file is generated; and, Update the multi-step summary report in the analysis session folder to add the new test step identifier and its corresponding statistical indicators to the multi-step summary report.

9. A production line test data analysis system, characterized in that, include: The acquisition module is used to acquire a set of multiple test result values ​​corresponding to multiple test step identifiers; The statistical indicator calculation module is used to fill the set of test result values ​​corresponding to each test step identifier into a template file with a pre-set calculation formula for calculating statistical indicators that characterize the production process characteristics, and trigger the calculation function of the template file to obtain the statistical indicator corresponding to the test step identifier. The generation module is used to generate a single-step analysis file containing statistical indicators for each test step identifier, based on a template file that has been populated with test result values ​​and completed calculations.

10. A computer device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the production line test data analysis method as described in any one of claims 1 to 8.

11. A computer program product, characterized in that, It includes a computer program that, when run, implements the production line test data analysis method as described in any one of claims 1 to 8.

Images