MBB product production test method and system
Through the interaction between the MES system and production tools, combined with unified data management and configuration files, the data silo problem in MBB product testing is resolved, efficient production data management and unified testing standards are achieved, and the reuse rate of production tools and product consistency are improved.
Patent Information
- Application Number
- CN202510733026.5
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-06-04
- Publication Date
- 2025-09-16
AI Technical Summary
The lack of a unified data management platform during traditional MBB product testing leads to difficulties in data traceability, inefficient statistical analysis, low tool reuse, long development cycles, and inconsistent implementation of testing standards. This increases manpower and time costs, and can easily lead to test failures or misjudgments due to interface differences.
Production test data is created through the MES system, product parameter rules are generated, and production tools interact with the MES system to collect and upload test results. A unified architecture and configuration files are used to manage test items, and a unified production test interface is defined to achieve rapid adaptation and automated testing of different MBB product models.
It realizes the centralized management and real-time synchronization of production data, improves the tool reuse rate, shortens the development cycle, reduces costs, ensures the uniformity of test standards and production yield, and improves product consistency.
Smart Images
Figure CN120655015A_ABST
Abstract
Description
Technical Field
[0001] The present application relates to the field of production and manufacturing technology, and in particular to a method and system for MBB product production testing. Background Art
[0002] With the rapid development of mobile communications technology, demand for mobile broadband (MBB) products in 5G and future networks is growing. Traditional MBB product testing relies on manual recording and file transfer, stored in decentralized systems, and lacks a unified data management platform. This makes data traceability difficult, statistical analysis inefficient, and real-time monitoring and optimization of the entire production process difficult, leading to severe information silos.
[0003] Furthermore, existing test tools are often customized for specific MBB product models and lack a universal architecture. This requires repeated development of test logic and interfaces for different product models, resulting in low tool reuse, extended development cycles, and increased labor and time costs. Furthermore, these differences between tools can lead to inconsistent implementation of test standards, impacting product consistency. The interface definitions between MBB products and test tools lack industry or enterprise-level standards, and different product models may utilize different communication protocols, instruction sets, or data formats. This non-standardized interface not only complicates test tool development but can also easily lead to test failures or misjudgments due to adaptation errors, reducing production yield. Summary of the Invention
[0004] To overcome the shortcomings of the existing technology, the present invention provides an MBB product production testing method and system. Through a unified architecture, this method implements full-process production data management, rapid adaptation of testing tools to different MBB product models, and automated testing.
[0005] A first aspect of the present application provides an MBB product production test method, which is applied to an MBB product production test system. The MBB product production test system includes an MES system and production tools. The method includes: The MES system creates production test data for the current MBB product and generates product parameter rules based on the production test data. When the production tool detects the start instruction, it obtains the production work order to be executed in the product parameter rule; The production tool loads a configuration file to determine test items to be executed for the current MBB product; The production tool obtains the product label of the current MBB product and sends a process inspection request to the MES system, where the process inspection request carries the product label and the name of the current process; The MES system verifies the to-be-executed production work order and process status according to the product label and the current process name, and transmits the verification result to the production tool; When the production tool determines that the verification result is passed, it calls the production test interface to execute the test item to be executed.
[0006] In an optional embodiment, the MES system verifies the pending production work order and process status according to the product label and the current process name, including: When receiving the process inspection request, the MES system verifies whether the product tag is bound to the current work order of the to-be-executed production work order, and obtains a first verification result; Verifying whether the current process is allowed to be executed based on the current process name, and obtaining a second verification result; When both the first verification result and the second verification result are verification passed, determining the verification result as verification passed; When either the first verification result or the second verification result is a verification failure, it is determined that the verification result is a verification failure.
[0007] In an optional embodiment, when the production tool determines that the verification result is passed, calling the production test interface to execute the to-be-executed test item includes: The production tool calls the MES-API interface of the MES system, so that the MES system returns the test parameters according to the production data acquisition request; The production tool writes the test parameters to the current MBB product through the production test interface, so as to execute the to-be-executed test items on the current MBB product.
[0008] In an optional embodiment, the method further comprises: The production tool matches a corresponding test template from the configuration file according to the product type of the current MBB product; The production tool determines the test order and the test parameters of the test items to be executed based on the test template.
[0009] In an optional embodiment, the production tool configures an ADB environment, and the method further includes: The production tool creates a bidirectional anonymous channel, the bidirectional anonymous channel including a first bidirectional anonymous channel and a second bidirectional anonymous channel, the first bidirectional anonymous channel including a first process reading end and a first process writing end, the second bidirectional anonymous channel including a second process reading end and a second process writing end; The production tool writes an ADB command through the first process write end, so that the ADB process reads the command through the first process read end; The ADB process outputs the execution result through the second process writing end, so that the production tool reads the execution result through the second process reading end.
[0010] In an optional embodiment, the method further comprises: The production tool sends a heartbeat detection command to the ADB process through the bidirectional anonymous channel; When the production tool does not receive a response instruction from the ADB process within a preset time, the production tool reinitializes the ADB environment.
[0011] In an optional embodiment, the method further comprises: The production tool determines the product requirements of the current MBB product and constructs the configuration file according to the product requirements; When receiving the newly added optional test item of the current MBB product, the production tool adds the newly added optional test item to the optional items in the configuration file.
[0012] In an optional embodiment, when the production tool determines that the verification result is passed, after calling the production test interface and executing the to-be-executed test item, the method further includes: The production tool collects test result data of the current MBB product and uploads the test result data to the MES system; The MES system updates the production status of the current MBB product according to the test result data, and generates a test report for the current MBB product.
[0013] A second aspect of the present application provides an MBB product production test system, the system comprising: an MES system and production tools; The MES system is configured to create production test data for the current MBB product and generate product parameter rules based on the production test data; The production tool is used to obtain the production work order to be executed in the product parameter rule after detecting the start instruction; The production tool is further configured to load a configuration file to determine test items to be executed for the current MBB product; The production tool is further configured to obtain a product label of the current MBB product and send a process inspection request to the MES system, where the process inspection request carries the product label and the name of the current process; The MES system is further configured to verify the pending production work order and process status according to the product label and the current process name, and transmit the verification result to the production tool; The production tool is further configured to, when determining that the verification result is a passed verification, call a production test interface to execute the test item to be executed.
[0014] In an optional embodiment, the system further includes a production test interface, which unifies the instruction set, data format and communication protocol.
[0015] In summary, the MBB product production testing method and system provided in this application have at least one of the following beneficial effects: 1. The MES system creates production test data and generates product parameter rules. Production tools interact with the MES system, collect test result data, and upload it to the MES system. The MES system updates the production status based on the test result data and generates a test report. This achieves centralized management and real-time synchronization of production data, avoids the tedious manual recording and file transfer, facilitates data traceability and statistical analysis, and can monitor the entire production process in real time, effectively solving the problem of information silos. 2. The production tool retrieves pending production work orders from the product parameter rules generated by the MES system and loads configuration files to determine the test items to be executed, eliminating the need for testing tools limited to specific MBB product models. Through unified product parameter rules and configuration file management, different product models can use the same production tool framework. Simply adjusting the parameter rules and configuration files can adapt to the testing requirements of different product models. This increases tool reuse, shortens development cycles, reduces labor and time costs, and ensures uniformity in the implementation of test standards, improving product consistency. 3. The production tool obtains the product tag and sends a process inspection request to the MES system. The MES system verifies the pending production work order and process status based on the product tag and current process information, and transmits the verification results to the production tool. This clarifies the interface specifications between the production tool and the MES system, avoiding issues caused by different communication protocols, instruction sets, or data formats for different product models. This unified interface definition simplifies the development of test tools, reduces test failures or misjudgments caused by adaptation errors, and improves production yield. BRIEF DESCRIPTION OF THE DRAWINGS
[0016] Figure 1 This is a schematic diagram of the structure of an MBB product production and testing system according to an embodiment of the present application; Figure 2 This is a flow chart of a method for producing and testing MBB products according to an embodiment of the present application. Figure 3This is another flowchart of an MBB product production and testing method shown in an embodiment of the present application. DETAILED DESCRIPTION
[0017] The present invention will be further described below with reference to the accompanying drawings and examples.
[0018] The following will clearly and completely describe the concept, specific structure and technical effects of the present invention in combination with the embodiments and drawings, so as to fully understand the purpose, characteristics and effects of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of them. Based on the embodiments of the present invention, other embodiments obtained by those skilled in the art without creative work are within the scope of protection of the present invention. In addition, all the connection / connection relationships involved in the patent do not refer to the direct connection of components, but refer to the fact that a better connection structure can be formed by adding or reducing connection accessories according to the specific implementation situation. The various technical features in the invention can be combined interactively without conflicting with each other.
[0019] Reference Figure 1 FIG. 1 is a schematic diagram of the structure of an MBB product production test system according to an embodiment of the present application. The MBB product production test system may include an MES system, production tools, and a production test interface.
[0020] In some embodiments, production tools are developed using VC++ and provide a human-computer interface (HMI) that displays MBB product models and work order information, executes automated functional testing interfaces, and performs product numbering, product data inspection, test record generation, and process execution status visualization. This application utilizes VC++ for production software development, achieving improved execution efficiency.
[0021] Since most MBB products use the Linux kernel, the Android Debug Bridge (ADB) is a debugging tool running on the Linux system, serving as an upper-layer application for external communication. It offers relative stability and efficiency, whether communicating via USB or Ethernet. In an embodiment of the present application, ADB provides a command-line interface (CLI) that allows external tools (such as production test software) to send commands, read device data, and write configurations. It also uses the Windows API to create two pairs of independent anonymous pipes: one for input, sending commands to the ADB process, and the other for output, receiving return data from the ADB process. This enables bidirectional asynchronous communication, separates input and output, and avoids data congestion. Compared to traditional ADB communication, which directly uses a single pipe for command-line interaction, in MBB product production testing, ADB is used for device communication and the Windows API's anonymous pipe technology is used to optimize interaction, making communication more stable and efficient. This method uses anonymous pipes to hide the command-line process's interaction with the product, ensuring more stable and controllable data input and output after establishing an ADB communication connection with the product, avoiding the blocking and congestion issues associated with traditional single-pipe solutions.
[0022] In some embodiments, all common test items, such as RF calibration, Wi-Fi throughput, and GPS positioning accuracy, are built into the production tool. A configuration file is used to determine which test items are required for the current MBB product. These test items are configured as switchable, and the acceptance ranges for some test item indicators are configurable. This means that the pass / fail criteria for test items (such as signal strength ranges and error tolerances) are no longer hard-coded but defined in the configuration file. Subsequently, the production tool reads the configuration file to initialize the test process and acceptance criteria, eliminating the need for code recompilation. Simply providing a single configuration file for each new MBB product model allows for switching test logic. Therefore, different MBB products can use the configuration file to set test items to execute and configure indicator acceptance ranges. The configuration file uses a structured format, such as JSON, XML, or a database table, to facilitate system parsing and manual maintenance. During MBB product testing, the production tool loads the contents of the configuration file at startup to initialize all information. The configuration file includes the acceptance ranges for test item indicators and the enable / disable switches for test items. Therefore, during product development, this application can quickly adapt to MBB product production requirements by simply modifying these configurations. Compared to traditional MBB product production testing, which requires customized test tools for different MBB product models, each product has different test items and indicator ranges, requiring separate test logic development. Furthermore, MBB product acceptance thresholds (such as the WiFi signal strength range) are written directly into the code, requiring recompilation for modifications. Furthermore, customized test tools cannot quickly adapt to new products, resulting in long development cycles and high maintenance costs. This application implements multi-model adaptation and dynamic adjustment of test standards in MBB product production testing. By driving test logic through configuration files, this enables one-time development and flexible adaptation, significantly reducing the test development costs for different products.
[0023] In some embodiments, because the MES system uses web services for external data exchange, production tools can interact with the MES system using the HTTP protocol, supporting both the GET and POST methods. Through the MES-API, production tools can obtain the data required for MBB product production, upload test records generated by the production tool, and update the production progress of a specific product. Generated test records are also backed up to local storage for storage. Using a unified format facilitates data retrieval, quickly locates problems, and shortens troubleshooting time.
[0024] In some embodiments, a production test interface for MBB products is designed, utilizing standardized interface specifications, including a unified instruction set, data format, and communication protocol. This unified instruction set ensures that different implementations of the same functionality across different products use the same external interface name and input parameter specifications. A unified data format returns test results as structured data (e.g., JSON). A unified communication protocol supports ADB command interaction, ensuring compatibility with different operating systems. This production test interface reduces the coupling between production tools and the underlying product implementations, enabling efficient integration between production tools and any MBB product. By designing and defining the production test interface, different MBB products adhere to a unified tool interface solution in their software implementation. Specific business processes are developed on the embedded side of the MBB product. Differences in functional testing implementation across different MBB products are addressed on the embedded software development side. After packaging, a unified, universal production test interface is provided externally. This reduces tool sensitivity to underlying instructions across different product platforms or chipsets. By using standardized interface names and call input parameter specifications, production tools can interact with multiple products using a unified method, enabling rapid adaptation.
[0025] Figure 2 This is a flow chart of an MBB product production and testing method shown in an embodiment of the present application. The MBB product production and testing method includes the following steps.
[0026] S21: Create production test data for the current MBB product, and generate product parameter rules based on the production test data.
[0027] In some embodiments, the MES system may include a product management module, a work order module, a process configuration module, a data storage module, and a web service. Users can add production test data for the current MBB product in the user interface (UI) provided by the MES system. This production test data may include, but is not limited to, product information (including product model, specifications, and version number), production orders (including production tasks, production quantities, and production time), and production processes (including production steps, process requirements, and quality control points). Work orders are issued through the MES system, and the required production data (such as IMEI and MAC address) is assigned to production equipment or production lines. Production test data can also be customized. Furthermore, customized product parameter regulations, such as Wi-Fi SSID and Wi-Fi Key, can be set based on the production test data, allowing subsequent work order modules to activate the work order production data using product parameter rules. The work order management module centrally manages all work orders for the current MBB product. The MES system's UI allows users to create pending production work orders for the current MBB product and activate the current MBB product to generate the necessary production parameters, such as the serial number (S / N), WiFi SSID, and WiFi key. By creating work orders, production data for different MBB products or batches can be isolated at the data level. By specifying a work order, production tools can retrieve production data within the scope of the work order, preventing the risk of data mixing between different products or batches.
[0028] The process configuration module uses system visualization to define the production process for the current MBB product. It creates the required process modules within the interface, names and defines them, and serially connects them according to the required production process sequence, forming the product's production flow. The system then manages production processes based on this defined production flow. The data storage module stores test records, production status, and product parameters uploaded by production tools to the MES system. This data is associated with the unique identifier (SN / IMEI) of the current MBB product under test. Therefore, the MES application layer can directly access the corresponding data records using the SN / IMEI of the current MBB product. Furthermore, the MES system uses Web services to communicate and exchange data with the other end (the MES system's visual interface / production tool) that requires integration with the MES system. It provides a standard interface (e.g., MES-API) and uses HTTP as the transport protocol. Data can be formatted as JSON. The JSON format offers strong platform compatibility, scalability, and maintainability. Clients, whether PCs, mobile phones, or industrial tablets, can call the interface via HTTP, eliminating the need for custom drivers. Adding new features simply requires extending the interface without modifying the client's core logic.
[0029] When production testing of the current MBB product is required, the MES system can obtain the production test data of the current MBB product in the product management module and process the production test data, for example, converting it into executable test standards such as voltage range and temperature threshold, and generating product parameter rules in combination with the production plan. Figure 3 Specifically, the MES system creates product information, production work orders, and production processes. Work orders are issued and production data (IMEI / MAC address) is allocated. Parameters such as serial number (SN), WiFi SSID, and WiFi key can be automatically generated based on specific rules. Production tasks are initialized to determine key information such as product type, quantity, and production time. Specific rules allow you to configure data rules for parameters when creating products. For example, specifying that the SN should be generated using a fixed prefix string, a two-digit year and a two-digit month, and a six-digit serial number; that the WiFi SSID should be generated using a fixed prefix string and the last four characters of the MAC address; and that the WiFi key should be composed of eight random digits and letters. The MES system pre-develops as many rules as possible. If a rule does not exist, it will be expanded. The MES system then distributes production test data to the corresponding production tools, providing guidance for subsequent production testing. Furthermore, this distributed production test data is stored in the production database, which serves as a central data storage center, ensuring the security and accessibility of production data.
[0030] Refer to Figure 3 In some embodiments, the MES system and production tools exchange data via HTTP. Production tools can obtain required production data from the production database through HTTP requests, and can also upload production test results to the production database through HTTP.
[0031] S22, when the start instruction is detected, obtaining the production work order to be executed in the product parameter rule.
[0032] In some embodiments, after the production tool is started, the MES-API can be used to retrieve all MBB product work orders, specifically the pending production work orders for the current MBB product. Before starting production testing for the current MBB product, a pending production work order can be specified on the work order display interface. The pending production work order can also be used to define the production test data range and production quantity.
[0033] S23: Load a configuration file to determine test items to be executed for the current MBB product.
[0034] In some embodiments, the production tool can scan the IMEI / SN barcode on the current MBB product label or read the IMEI / SN from the product. It then calls the MES API to retrieve a list of all currently available production work orders from the MES system. On the production tool's work order display interface, the operator selects a specific work order based on production requirements (such as product model, batch, and delivery date). After selecting the work order, the production tool uses the information in the work order (such as product parameters and production quantity) to define the data range for subsequent production tests. The production tool then loads a configuration file corresponding to the current MBB product model, IMEI / SN, from local storage or a server. By parsing the configuration file, the tool determines the test items to be executed on the current product, referred to as pending test items. The configuration file is pre-built and deployed in the production tool.
[0035] In an optional embodiment, the method further comprises: The production tool determines the product requirements of the current MBB product and constructs the configuration file according to the product requirements; When receiving the newly added optional test item of the current MBB product, the production tool adds the newly added optional test item to the optional items in the configuration file.
[0036] In some embodiments, a standardized set of production test interfaces (such as TestInterface) is defined to encapsulate common functions such as hardware control, parameter reading and writing, and data collection. This allows different MBB product models to implement test logic by inheriting or combining these interfaces, avoiding duplication of development. MBB product-specific test processes, parameters, and thresholds are defined in a configuration file (such as JSON / YAML). Production tools dynamically generate test processes by parsing the configuration file, eliminating the need for code modifications. The configuration file can include a list of test items (e.g., name, threshold, timeout period), device parameters (e.g., firmware version, calibration values), and optional plug-ins (e.g., to add special functions). After the configuration file is built based on the product requirements of the current MBB product, it can be deployed in the production tool environment. When the production tool starts, the configuration file is automatically loaded without recompiling. When testing the current MBB product, the production tool can execute the test items in the order specified in the configuration file. After each test item is completed, the production tool compares the test results with the thresholds in the configuration file and reports whether the test has passed or failed. Additionally, if a new test is required for the current MBB product, the new test can be added as an optional test item to the configuration file. Specifically, the production tool can add the execute_temperature_test method (with an empty implementation by default) to the TestInterface, update the configuration file template, and add the optional test item field.
[0037] The above optional implementation method, through a unified production test interface and configuration file-driven testing, can improve the efficiency of the production introduction cycle of new MBB products. Production tools only need to edit configuration files according to MBB product requirements, without the need for code development. New common requirements only need to be expanded and added to the configuration options.
[0038] S24: Obtain a product label of the current MBB product and send a process inspection request to the MES system.
[0039] The process verification request carries the product label and the current process name. When a barcode scanner scans the IMEI / SN barcode on the MBB product label, or reads the IMEI / SN from a built-in memory chip (such as an EEPROM) in the MBB product, the production tool encapsulates the acquired IMEI / SN and the current process name into a process verification request and sends it to the MES system via the MES-API.
[0040] S25, verifying the to-be-executed production work order and process status according to the product label and the current process name, and transmitting the verification result to the production tool.
[0041] The MES system receives and parses the process inspection request, extracts the IMEI / SN and process name, indexes the corresponding production test data in the database based on the IMEI / SN, and verifies whether the current MBB product belongs to the current work order to be executed and whether the current process belongs to the next process in the production process.
[0042] In an optional embodiment, the MES system verifies the pending production work order and process status according to the product label and the current process name, including: When receiving the process inspection request, the MES system verifies whether the product tag is bound to the current work order of the to-be-executed production work order, and obtains a first verification result; Verifying whether the current process is allowed to be executed based on the current process name, and obtaining a second verification result; When both the first verification result and the second verification result are verification passed, determining the verification result as verification passed; When either the first verification result or the second verification result is a verification failure, it is determined that the verification result is a verification failure.
[0043] In some embodiments, upon receiving a process verification request, the MES system verifies both the work order binding relationship and the process execution authority, and returns a final result based on a comprehensive assessment. Specifically, the MES system receives the process verification request from the production tool via the MES-API interface, extracts the product tag (e.g., IMEI / SN) and the current process name (e.g., PCB assembly, burn-in test) in the process verification request, verifies whether the product tag falls within the legal range of the currently pending production work order, and obtains a first verification result. It also verifies whether the current process complies with the sequence requirements of the production process, obtaining a second verification result. Only if both verifications pass is the production tool allowed to continue the test; otherwise, the process terminates and returns an error message. When performing the work order binding verification, the MES system queries the database based on the product tag (e.g., IMEI / SN) to obtain the product's production information, including the work order ID, product model, batch number, and current production status (e.g., "to be produced," "in production," or "completed"). The retrieved work order ID is then compared with the ID of the pending production work order. If they match, the product tag belongs to the current work order, and the first verification passes. If they do not match or no record is found, the first verification fails. By verifying the work order binding relationship, we ensure that the product tag is legally associated with the production work order to be executed, and prevent the misuse of other work orders or illegal products.
[0044] When performing process execution permission verification, the MES system queries the preset production process template (such as the BOM or process routing) based on the product model to obtain a list of standard processes and their sequence for the current MBB product, such as Process 1: PCB Assembly; Process 2: SMT Placement; and Process 3: Functional Testing. It then queries the current production progress based on the product tag, obtaining a list of completed processes and their current status. For example, completed processes: PCB Assembly, SMT Placement; current process status: Waiting for "Functional Testing." The system then compares the current process name in the request with the product process definition and its current status. If the process name matches the next process in the process, the second verification passes. If the process name does not match (e.g., skipping "Functional Testing" and directly executing "Burning Test"), the second verification fails. This process execution permission verification ensures that the current process is the next permitted process in the production process, preventing process skipping or duplication. In other embodiments, if the product tag is not bound to any work order (e.g., for a newly commissioned product), the system can check whether an initial work order has been assigned. Alternatively, if the product tag is bound to another work order (e.g., for a reworked product), cross-work order operations must be verified. If a current MBB product requires rework and a process repeats, the system must verify that the rework indicator has been applied. If the production process changes (such as adding a new process), the system must verify that the process template has been updated. Furthermore, the MES system can confirm the availability of process resources (such as testing equipment and operator permissions).
[0045] In some embodiments, if the MES system times out when querying the database, it can return a temporary error and support retrying by the production tool. At the same time, it can cache frequently queried work orders and process data to reduce database pressure. Non-critical processes (such as auxiliary processes) can be configured to be skipped and marked in the process template.
[0046] Through the above optional implementation method, production confusion is avoided by legally binding product labels to work orders, and the sequential execution of processes complies with production process specifications, and the traceability of the verification process facilitates problem troubleshooting and auditing.
[0047] S26: When the production tool determines that the verification result is passed, it calls the production test interface to execute the test item to be executed.
[0048] In some embodiments, after verification, the production tool will begin testing. To write device parameters to the current MBB product, the production tool sends a data acquisition request to the MES system through the MES-API. The MES system returns all indexed parameters based on the request, and the production tool writes the acquired parameters into the product. Writing parameters to the current MBB product is performed by calling the product tool's general production test interface. After all pending test items of the production tool are executed, the test results are uploaded through the MES-API.
[0049] In an optional embodiment, when the production tool determines that the verification result is passed, calling the production test interface to execute the to-be-executed test item includes: The production tool calls the MES-API interface of the MES system, so that the MES system returns the test parameters according to the production data acquisition request; The production tool writes the test parameters to the current MBB product through the production test interface, so as to execute the to-be-executed test items on the current MBB product.
[0050] In some embodiments, production tools use a locally configured or dynamically loaded test interface library to call universal production test interfaces that match current MBB products. These interfaces include hardware control (such as power supply and oscilloscope) or software functions (such as firmware burning and parameter configuration). The production tools read a list of pending test items (such as voltage test and signal integrity test) from the configuration file, determine the test sequence for each test item, and monitor anomalies (such as device timeout and data limit exceeding) in real time during the test process and log them. Specifically, the production tool sends a parameter request through the MES-API. The request includes the product tag (IMEI / SN), the current process name (such as "Functional Test"), and the work order ID (optional, for parameter version control). Based on the product tag and process name, the MES system queries the database to obtain the associated parameter set, including the firmware version, calibration data, and configuration file path. It then returns the test parameters in a data format (for example, JSON). The production tool then calls the parameter write function of the universal production test interface to write the test parameters to the current MBB product. The firmware is burned to the current MBB product via the serial port, USB, or network, and the calibration data is written using a tool function (such as WriteEEPROM()). After writing the test parameters, the effectiveness of the test parameters must be verified. Once the test parameters are confirmed to be effective, testing of the current MBB product begins according to the pending test items. The production tool then collects the results (pass / fail), raw data, and timestamps of all test items to generate a structured report. After the production tool receives the test report, it can send it to the MES system via the MES-API (e.g., POST / api / test-results). The MES system associates the results with the product label, work order, and process and stores them in the database. For example, after the production tool passes verification, it calls the test interface to perform a "voltage test" and a "signal integrity test." It obtains test parameters from the MES, including firmware version V1.2.3 and calibration data offset = 0.01. The parameters are written and verified. After all tests pass, the results are uploaded to the MES. If the "signal integrity test" fails, the production tool marks the product as unqualified, and the MES system routes it to the rework area.
[0051] Refer to Figure 3 After obtaining production test data, the production tool executes pending tests based on the data. These pending tests may include functional testing, performance testing, and compatibility testing, depending on the characteristics of the MBB product and production requirements. During the testing process, the production tool needs to interact directly with the current MBB product, controlling it and collecting data through interfaces such as ADB.
[0052] Through the above optional implementation methods, test parameter configuration management is used to ensure that the product uses the latest and correct configuration, and automatically tests according to the test items to be executed, reducing manual intervention, improving consistency and efficiency, generating tools and returning test results to the MES system, and realizing full-link traceability of production data.
[0053] In an optional embodiment, when the production tool determines that the verification result is passed, after calling the production test interface and executing the to-be-executed test item, the method further includes: The production tool collects test result data of the current MBB product and uploads the test result data to the MES system; The MES system updates the production status of the current MBB product according to the test result data, and generates a test report for the current MBB product.
[0054] In some embodiments, after the production tool completes all test items, it can collect test result data, including test item execution results (PASS / FAIL), key parameter values (such as signal strength, power consumption, and throughput), error logs (such as detailed error messages when a test fails), and device information (such as SN, IMEI, and firmware version). After obtaining the test result data, the production tool can upload the test result data via the REST API or MQTT message queue provided by the MES system to ensure real-time data synchronization. After receiving the test result data, the MES system verifies the integrity of the test result data (for example, whether the SN matches the current work order), verifies that all test items have been executed to prevent missed tests, and determines whether the production test result is a pass or fail. If the production test result is determined to be a pass, it is marked as TEST_PASS and the next process (such as packaging) is entered. If the production test result is determined to be a fail, it is marked as TEST_FAIL, triggering a repair work order (RMA). The MES system can also automatically generate a traceable test report based on the test result data, which supports multiple formats such as PDF and HTML.
[0055] This optional implementation eliminates manual intervention from test execution to report generation. Production tools automatically collect and upload test result data to the MES system, ensuring real-time data synchronization. The MES system then updates production status and generates test reports based on this data, enabling rapid feedback and accurate documentation of test results. Furthermore, integrity checks and missed test prevention ensure test quality, and test results automatically trigger subsequent processes or repair work orders, improving production efficiency and product quality control.
[0056] In an optional embodiment, the production tool configures an ADB environment, and the method further includes: The production tool creates a bidirectional anonymous channel, the bidirectional anonymous channel including a first bidirectional anonymous channel and a second bidirectional anonymous channel, the first bidirectional anonymous channel including a first process reading end and a first process writing end, the second bidirectional anonymous channel including a second process reading end and a second process writing end; The production tool writes an ADB command through the first process write end, so that the ADB process reads the command through the first process read end; The ADB process outputs the execution result through the second process writing end, so that the production tool reads the execution result through the second process reading end.
[0057] In some embodiments, the ADB toolchain can be installed on the system where the production tool runs to enable interaction between the production tool and the current MBB product. The system environment variable PATH is configured in the production tool to ensure that adb commands can be directly called from the command line. The current MBB product is in USB debugging mode (or network debugging mode) and connected to the host (USB / Ethernet) where the production tool is located. Then, manually execute the command adb devices from the command line to confirm that the current MBB product is included in the device list and is in the device state, thus ensuring that the current MBB product is online. Specifically, a bidirectional anonymous pipe pair is created: an input channel (referred to as the first bidirectional anonymous channel) and an output channel (referred to as the second bidirectional anonymous channel). The first bidirectional anonymous channel includes the first process read port (hChildStd_IN_Rd) and the first process write port (hChildStd_IN_Wr). The second bidirectional anonymous channel includes the second process read port (hChildStd_OUT_Rd) and the second process write port (hChildStd_OUT_Wr). Because the production tool is developed on the Windows platform, it calls Windows APIs (such as CreatePipe and CreateProcess) to create hChildStd_IN_Rd and hChildStd_IN_Wr. hChildStd_IN_Wr is written to by the production tool and is bound to the standard input of the ADB process. Furthermore, the production tool calls Windows APIs (such as CreatePipe and CreateProcess) to create hChildStd_OUT_Rd and hChildStd_OUT_Wr. hChildStd_OUT_Rd is read from by the production tool and is bound to the standard output of the ADB process. The production tool can send an adb devices call via hChildStd_IN_Wr and read hChildStd_IN_Rd to confirm that the MBB product is online. Once the MBB product is confirmed to be online, test commands can be sent via XX to simulate user operations and execute the desired test items, such as stress testing, on the MBB product.
[0058] In some embodiments, the production tool can also monitor the bidirectional anonymous channel for read and write errors and use error codes to determine whether the ADB process terminated unexpectedly. Furthermore, after communication ends, the production tool can close all pipe handles and terminate the ADB process to free up system resources. This optional implementation enables efficient and stable interaction with ADB, making it suitable for large-scale automated testing scenarios for MBB products.
[0059] In an optional embodiment, the method further comprises: The production tool sends a heartbeat detection command to the ADB process through the bidirectional anonymous channel; When the production tool does not receive a response instruction from the ADB process within a preset time, the production tool reinitializes the ADB environment.
[0060] In some embodiments, the production tool can periodically (e.g., every 5 seconds) send a heartbeat detection command (e.g., adb shell echo "PING") through a bidirectional anonymous channel and wait for the ADB process to return a "PONG" (or other ACK signal) through the response channel. Specifically, the production tool writes a heartbeat detection command, such as PING, through the first process write end. The ADB process reads and executes the heartbeat detection command through the first process read end, and then returns PONG through the second process write end. After sending the heartbeat detection command, the production tool starts a timer (e.g., with a preset timeout of 3 seconds). If a PONG is not received through the second process read end before the timeout, the ADB process is determined to be unresponsive. If the ADB process is determined to be unresponsive, the production tool forcibly terminates the ADB process by calling taskkill (Windows) or kill (Linux), closing all ADB-related ports (e.g., 5037), releasing the pipe handle, and preventing resource leaks. The ADB service is then restarted (adb start-server), reestablishing the bidirectional anonymous channel and resuming communication. If the ADB restart fails, the production tool reports an error (such as ADB_INIT_FAIL) to the MES system, suspends the current work order, and records the heartbeat timeout and ADB restart events for subsequent analysis (for example, writing to the database through the MES system's Log-API).
[0061] Through the above optional implementation, heartbeat detection is used to avoid ADB freezing and test stalls, and the ADB environment is automatically reinitialized without manual intervention.
[0062] This application builds a complete closed-loop MBB product production test system through the MES system, production tools, and production test interfaces. The MES system provides production test data, defines the production test process, and transfers and stores data. The production tools communicate with the MES system via the HTTP protocol. ADB interacts with MBB products, and human-computer interaction implements manual / automatic testing. JSON parses and analyzes data, configuration files differentiate different MBB products, and data backup ensures security, ultimately achieving efficient, flexible, and reliable production testing. The MBB product production test interface defines a unified instruction set and data format to enable unified testing for all MBB products.
[0063] It should be noted that for the aforementioned method embodiments, for ease of description, they are all expressed as a series of action combinations. However, those skilled in the art should be aware that the present invention is not limited by the order of the actions described, because according to the present invention, certain steps can be performed in other orders or simultaneously. Secondly, those skilled in the art should also be aware that the embodiments described in this specification are all preferred embodiments, and the actions and modules involved are not necessarily required by the present invention.
[0064] In the above embodiments, the description of each embodiment has its own focus. For parts that are not described in detail in a certain embodiment, reference can be made to the relevant descriptions of other embodiments.
[0065] The above is a specific description of the preferred implementation of the present invention, but the invention is not limited to the embodiments. Those skilled in the art can make various equivalent modifications or substitutions without violating the spirit of the present invention. These equivalent modifications or substitutions are all included in the scope defined by the claims of this application.
Claims
1. A MBB product production testing method, characterized in that: Applied to an MBB product production test system, the MBB product production test includes an MES system and production tools. The method includes: The MES system creates production test data for the current MBB product and generates product parameter rules based on the production test data. When the production tool detects the start instruction, it obtains the production work order to be executed in the product parameter rule; The production tool loads a configuration file to determine test items to be executed for the current MBB product; The production tool obtains the product label of the current MBB product and sends a process inspection request to the MES system, where the process inspection request carries the product label and the name of the current process; The MES system verifies the to-be-executed production work order and process status according to the product label and the current process name, and transmits the verification result to the production tool; When the production tool determines that the verification result is passed, it calls the production test interface to execute the test item to be executed.
2. The MBB product production testing method according to claim 1, characterized in that: The MES system verifies the pending production order and process status according to the product label and the current process name, including: When receiving the process inspection request, the MES system verifies whether the product tag is bound to the current work order of the to-be-executed production work order, and obtains a first verification result; Verifying whether the current process is allowed to be executed based on the current process name, and obtaining a second verification result; When both the first verification result and the second verification result are verification passed, determining the verification result as verification passed; When either the first verification result or the second verification result is a verification failure, it is determined that the verification result is a verification failure.
3. The MBB product production testing method according to claim 1, characterized in that: When the production tool determines that the verification result is passed, calling the production test interface to execute the test item to be executed includes: The production tool calls the MES-API interface of the MES system, so that the MES system returns the test parameters according to the production data acquisition request; The production tool writes the test parameters to the current MBB product through the production test interface, so as to execute the to-be-executed test items on the current MBB product.
4. The MBB product production testing method according to claim 3, characterized in that: The method further comprises: The production tool matches a corresponding test template from the configuration file according to the product type of the current MBB product; The production tool determines the test order and the test parameters of the test items to be executed based on the test template.
5. The MBB product production testing method according to claim 1, characterized in that: The production tool configures an ADB environment, and the method further includes: The production tool creates a bidirectional anonymous channel, the bidirectional anonymous channel including a first bidirectional anonymous channel and a second bidirectional anonymous channel, the first bidirectional anonymous channel including a first process reading end and a first process writing end, the second bidirectional anonymous channel including a second process reading end and a second process writing end; The production tool writes an ADB command through the first process write end, so that the ADB process reads the command through the first process read end; The ADB process outputs the execution result through the second process writing end, so that the production tool reads the execution result through the second process reading end.
6. The MBB product production and testing method according to claim 5, characterized in that: The method further comprises: The production tool sends a heartbeat detection command to the ADB process through the bidirectional anonymous channel; When the production tool does not receive a response instruction from the ADB process within a preset time, the production tool reinitializes the ADB environment.
7. The MBB product production and testing method according to claim 1, characterized in that: The method further comprises: The production tool determines the product requirements of the current MBB product and constructs the configuration file according to the product requirements; When receiving the newly added optional test item of the current MBB product, the production tool adds the newly added optional test item to the optional items in the configuration file.
8. The MBB product production testing method according to claim 1, characterized in that: When the production tool determines that the verification result is passed, calling the production test interface and executing the test item to be executed, the method further includes: The production tool collects test result data of the current MBB product and uploads the test result data to the MES system; The MES system updates the production status of the current MBB product according to the test result data, and generates a test report for the current MBB product.
9. An MBB product production test system, characterized in that: The system includes an MES system and production tools; The MES system is configured to create production test data for the current MBB product and generate product parameter rules based on the production test data; The production tool is used to obtain the production work order to be executed in the product parameter rule after detecting the start instruction; The production tool is further configured to load a configuration file to determine test items to be executed for the current MBB product; The production tool is further configured to obtain a product label of the current MBB product and send a process inspection request to the MES system, where the process inspection request carries the product label and the name of the current process; The MES system is further configured to verify the pending production work order and process status according to the product label and the current process name, and transmit the verification result to the production tool; The production tool is further configured to, when determining that the verification result is a passed verification, call a production test interface to execute the test item to be executed.
10. The MBB product production test system according to claim 9, characterized in that: The system also includes a production test interface that unifies instruction sets, data formats, and communication protocols.