An intelligent PCB function detection method, system and electronic device

Abstract

The present application relates to the technical field of electronic manufacturing automation testing, and in particular to a kind of intelligent PCB function detection method, system and electronic equipment.The method mainly contains receiving test configuration instruction and loading dynamic test configuration file, and test item is divided into two groups;Interface synchronously displays double test windows corresponding to two groups of tests respectively.Firstly, the first group of tests is executed concurrently, and the results, measured values and time consumption are displayed in real time, the remaining time consumption is predicted, and the threshold value is warned;After the first group is qualified, the cooperative instruction is automatically triggered, the second group of tests is started, and the progress and results are displayed in real time.The present application can solve how to efficiently and intelligently test single PCB with multiple modules concurrently under the premise of ensuring test logic correctness and resource coordination, and realize real-time predictive linkage of test progress and production line rhythm, to break through the efficiency bottleneck of existing serial testing and the problem of test station and production line scheduling disconnection.

Description

Technical Field

[0001] This invention relates to the field of automated testing technology in electronic manufacturing, specifically to a method, system, and electronic device for functional testing of intelligent PCB boards. Background Technology

[0002] In existing technologies, how to efficiently and collaboratively complete the testing of numerous functional modules on a PCB board at a single testing station, while ensuring that the testing process is closely linked to the production line rhythm to maximize overall production efficiency, has long been a core challenge in this field. The root of this problem lies in the numerous PCB board testing items, each with significantly different hardware resource requirements and testing times. Traditional serial testing (testing A before testing B) inevitably leads to long testing cycles and low station utilization. Simply launching multiple parallel testing tasks lacks an intelligent coordination mechanism, failing to guarantee the logical correctness of the testing process and efficient resource utilization, and further hindering the dynamic matching of the test station's real-time status with the entire production line's operating rhythm. This causes the testing station to become a bottleneck affecting the overall efficiency of the production line.

[0003] To address the aforementioned challenges of efficient collaborative testing and production line integration, existing technologies primarily propose two solutions. The first is to employ a multi-task independent testing system. This approach attempts to simultaneously test different functional modules of the PCB board by launching multiple independent test programs or processes. For example, running a USB test program, an audio test program, and a battery test program simultaneously within the operating system achieves a superficial parallel testing effect. However, this approach suffers from a lack of coordination and resource conflicts. The test programs operate completely independently, lacking information exchange and collaborative logic. They may simultaneously compete for the same hardware resources, leading to test failures or unreliable results. Each independent program focuses only on completing its own test task, failing to assess the overall testing progress of the PCB board from a global perspective, let alone predict remaining time. The production scheduling system cannot obtain effective collaborative signals from these dispersed programs to guide subsequent workstation operations.

[0004] Another solution is to use hardwired testing combining a programmable logic controller (PLC) and tooling fixtures. This approach involves designing dedicated hardware test fixtures and sensing circuits for each critical test item, with centralized control and signal acquisition via the PLC. Through a pre-programmed PLC, some test actions can be controlled to overlap slightly in time, and all test results can be aggregated. The disadvantages are poor flexibility and high cost. This solution heavily relies on customized hardware fixtures and wiring; if the PCB model or test item changes, the hardware fixture needs to be redesigned, manufactured, and debugged, and the PLC program rewritten. This results in slow response times, extremely high modification costs, and an inability to adapt to the flexible production needs of rapid product iteration. Furthermore, there are issues with low intelligence and limited collaboration. The test logic of the PLC program is usually fixed and sequential. While it can achieve simple timing control, it struggles to implement dynamic conditional branching and intelligent triggering based on real-time test results. Its parallel capabilities are limited by the hardwired design, making it very rigid. Such systems typically operate as closed automated units, and their internal states are difficult to feed back to upper-level systems such as MES in real-time and in a rich manner through standard interfaces. It cannot proactively send early warning signals to coordinate with the production line; it still passively performs tests, thus contributing little to optimizing the production line's cycle time.

[0005] There are two main solutions: one sacrifices collaboration and controllability to achieve superficial parallelism, while the other sacrifices flexibility and intelligence to achieve limited hardware-level synchronization. Neither can achieve truly efficient and intelligently schedulable collaborative testing while ensuring correct test logic and conflict-free resources. More importantly, neither solves the information and collaboration barriers between the test station and the production line, failing to transform real-time performance data from the test station into effective input for guiding overall line optimization and scheduling. This makes the testing phase a passive bottleneck hindering production efficiency improvement rather than a proactive optimization point. Summary of the Invention

[0006] This application provides an intelligent PCB board functional testing method, system, and electronic device, which can solve the problem of how to efficiently and intelligently perform multi-module concurrent testing on a single PCB board while ensuring the correctness of the test logic and resource coordination, and realize real-time predictive linkage between test progress and production line cycle time, so as to overcome the efficiency bottleneck of existing serial testing technology and the problem of disconnect between test station and production line scheduling.

[0007] Firstly, this application provides a method for functional testing of an intelligent PCB board.

[0008] A method for functional testing of an intelligent PCB board includes the following steps: Receive test configuration instructions and load the dynamic test configuration file associated with the PCB board under test. The dynamic test configuration file defines the judgment conditions for multiple test items divided into the first test group and the second test group. A first test window and a second test window are synchronously rendered and displayed on a graphical user interface, wherein the first test window is used to monitor and execute test items in the first test group, and the second test window is used to monitor and execute test items in the second test group; Initiate concurrent test execution for the first test group, and update the execution results, actual measurement values, and time consumption information of each test item in real time in the first test window; The system analyzes the execution time distribution of completed test items in the first test group in real time, and predicts the remaining total time of the current test session based on historical data. When the predicted time exceeds the preset production line cycle time threshold, it automatically generates and sends an early warning signal to adjust the operation sequence of subsequent workstations on the production line. The execution results of all test items in the first test group are detected in real time, and a collaborative start command is automatically generated and triggered when the execution results of all test items in the first test group meet the preset pass conditions. Based on the collaborative start command, the test execution for the second test group is initiated, and the test progress and results of the second test group are updated in real time in the second test window.

[0009] By adopting the above technical solution, and through the independently controlled first and second test windows on the left and right screens, concurrent execution of test tasks within the limits of hardware resources is achieved. Furthermore, through a collaborative mechanism of status monitoring and condition triggering, the two originally sequential test processes are organically linked, effectively compressing test idle waiting time and significantly shortening the overall test cycle of a single PCB board, thus improving the utilization rate of the test station. Real-time time consumption analysis of completed test items in the first test group and prediction of remaining time consumption based on historical data modeling enable the test system to proactively collaborate with the manufacturing execution system. When the predicted total remaining time exceeds the preset production line cycle time threshold, the system can issue an early warning signal to the production line, providing a valuable decision-making window for the scheduler to dynamically adjust the work sequence of subsequent workstations. This fundamentally changes the role of testing stations as passive data collection points in existing technologies, transforming them into intelligent nodes that actively participate in production process optimization. It effectively avoids the "traffic jam" problem caused by the extended processing time of a single testing station due to complex test items or occasional anomalies, which leads to subsequent stations waiting for materials and a decrease in overall line efficiency. It achieves a leap from isolated single-point testing to predictive testing in collaboration with the production line, and solves the problem of the lag in production scheduling's response to anomalies in the testing process.

[0010] Further, the step of initiating test execution on the first test group includes: Parse the test modes defined for each test item in the dynamic test configuration file, wherein the test modes include at least command-line test mode and file inspection test mode; When the test mode is command-line test mode, a command-line executor adapted to the current operating system is invoked. A predefined regular expression for the external executable program path, command-line parameters, timeout threshold, and expected output result is passed to the command-line executor. The standard output stream and standard error stream during the execution of the external executable program are captured. The text content of the standard output stream and / or standard error stream is matched and analyzed according to the regular expression to obtain the actual measurement value of the test item. When the test mode is the file inspection test mode, the target inspection file is located according to the predefined file path rules, and the complete content or specific data blocks of the target inspection file are read. By calling the preset file content parsing script or library, the read content is subjected to keyword retrieval, numerical extraction or structured data comparison to obtain the actual measurement value of the test item.

[0011] By adopting the above technical solutions, the command-line testing mode can directly call the hardware vendor's or the system's built-in low-level diagnostic tools, obtaining the most direct hardware status and performance parameters by parsing their standard output. This is suitable for testing scenarios that require command interaction with onboard controllers and sensors. The file inspection mode is suitable for scenarios that rely on external independent testing programs to generate result files, or that need to verify specific content in system logs or configuration files. This hybrid support for both modes allows the system to seamlessly adapt to diverse testing needs of different functional modules, different driver interfaces, and different firmware versions, significantly enhancing the versatility and scalability of the testing system. It avoids the repetitive work of developing dedicated testing modules for each test type and reduces system maintenance complexity.

[0012] Further, the step of initiating test execution on the first test group includes: During the execution of the external executable program, an audio verification signal of a specific frequency and mode is output to the test environment. The echo signal is monitored by the audio acquisition circuit built into the PCB board under test. By comparing the frequency attenuation and phase delay of the output audio verification signal with the received echo signal, the acoustic background noise level of the current test environment is dynamically evaluated. If the background noise level exceeds the preset threshold, the final judgment result of the current test item is marked as "environmental interference warning" and noise level information is added.

[0013] By adopting the above technical solution, the current ambient noise level can be accurately quantified, and the data can be strongly correlated with the test results as "metadata." In PCB board functional testing, the results of audio-related test items are highly susceptible to interference from background noise in the workshop environment. Traditional methods struggle to distinguish whether test failures are due to hardware malfunctions or excessive ambient noise. This solution provides crucial contextual information for test result determination by simultaneously conducting active acoustic detection during test execution: when an audio test fails, the operator or quality system can immediately check the associated ambient noise level. If the noise exceeds the standard, the result can be marked as being caused by environmental interference, thus avoiding misjudging failures caused by environmental factors as product hardware defects, reducing unnecessary retesting and repair costs, and improving the accuracy of quality assessment. Simultaneously, the long-term accumulated ambient noise data also provides objective evidence for environmental improvement and standardized management in the production site.

[0014] Furthermore, the step of updating the execution result of each test item in real time in the first test window includes: The judgment threshold configured for the current test item is read from the dynamic test configuration file. The judgment threshold includes any one or more of the following: numerical upper and lower boundary values, string expected matching values, specific strings that the file content must contain, or process identifiers that the process must exist. The actual measured value of the obtained test item is compared with the judgment threshold, and a deterministic judgment result is generated according to the preset judgment logic. The judgment logic is as follows: if the actual measured value is a numerical value, it is determined whether it falls within the closed interval formed by the upper boundary value and the lower boundary value; if the actual measured value is a string, it is determined whether it is completely consistent with the expected matching value or matches the specified pattern; if the test mode is a file inspection mode, it is determined whether the content of the target inspection file contains the specific string.

[0015] By adopting the above technical solution, the test judgment logic is fully configurable and automated. By extracting the judgment conditions from the program code and placing them in a dynamic configuration file, adjustments to test standards and adaptations to test items for different product models can be made without modifying the software itself; only the configuration file needs to be updated, greatly improving the test system's agility in responding to production changes. The judgment process is automatically executed based on preset, unambiguous logic, completely eliminating the subjectivity and inconsistency of manual interpretation, ensuring the objectivity and fairness of test results. Simultaneously, the real-time graphical updates of the judgment results provide operators with extremely intuitive status feedback, enabling them to instantly grasp the overall test progress and the health status of each module, significantly improving human-computer interaction efficiency and anomaly response speed.

[0016] Further, the step of real-time detection of the execution results of all test items in the first test group, and automatic generation of a collaborative start command when all test items meet the preset pass conditions, includes: After the last test item in the first test group is completed, or the first test window status monitoring thread periodically polls, the execution result status indicators of all test items in the first test group are traversed and checked. During the traversal inspection, if it is found that the actual measurement value of a certain test item falls exactly on the boundary value of its judgment threshold, an additional boundary value verification test is initiated. The boundary value verification test re-acquires the actual measurement value of the test item by improving the sampling accuracy, extending the sampling time, or using a higher precision measurement command, and uses the actual measurement value obtained after verification as the final judgment basis. If and only if the pass condition is met, the first test window status monitoring thread or the main scheduling thread creates an internal system event "first group of tests completed and passed" as a trigger signal, calls the test executor initialization entry function of the second test group, and thus generates the collaborative start instruction; If at least one execution result in the first test group is in a failed state, or if an actual measurement value is not successfully obtained, the collaborative start instruction will not be generated, and the second test window will remain in a waiting state.

[0017] By adopting the above technical solution, the accuracy and reliability of the collaborative start command triggering are ensured. This is the foundation for the automatic and smooth operation of the entire dual-window architecture, avoiding data chaos or resource conflicts caused by premature or incorrect start of subsequent tests due to misjudgment of the status of the preceding test group. In engineering practice where measurement inherently has errors, a measurement value that falls exactly on the pass / fail boundary may actually indicate a hardware status in a gray area between pass and fail. Through precise status traversal checks and strict pass / fail condition judgments, intelligent logic of reasonable skepticism and prudent decision-making is introduced. When a boundary value is detected, a higher-confidence review process is automatically triggered. This greatly reduces the probability of misjudging a critically passable product as fail or a critically failable product as pass due to fluctuations in a single measurement, significantly improving the scientific nature of test judgments and the rigor of quality control.

[0018] Furthermore, it also includes the following steps: automatically uploading the test result dataset to a specified remote server, including: After the test is completed and the final test result dataset is generated, the system automatically starts an asynchronous file upload task; The asynchronous file upload task first serializes the test result dataset into a structured data file according to a preset format; When serializing the structured data file, a preset symmetric encryption algorithm and key are used to encrypt sensitive data fields containing the actual measurement value, product serial number and operator identifier, and the encrypted ciphertext data replaces the original field values. At the same time, the initial vector used for encryption is stored in the file as a non-sensitive field, so that only the server with the corresponding decryption key can read the test results completely. The asynchronous file upload task uploads the structured data file to a pre-configured remote server directory through a file transfer protocol, a secure file transfer protocol, or a file upload interface based on the hypertext transfer protocol. During the upload process, the upload progress percentage and status text are updated in real time on the graphical user interface. After the upload is completed, the operation log records the upload success or failure event and the corresponding server path.

[0019] By adopting the above technical solutions, the automated and standardized archiving of test results replaces the tedious traditional manual copying, renaming, and uploading operations, ensuring the timeliness and consistency of data archiving and providing a complete and standardized data source for subsequent data analysis, quality traceability, and production report generation. The "end-to-end encryption" mechanism integrated into the data serialization process provides strong security for test data. Sensitive production data is encrypted before leaving the testing terminal, forming a secure channel of encryption at the source and decryption at the destination. Even if data files are intercepted during transmission or encounter unauthorized access while stored on the server, attackers cannot obtain commercially valuable core test information. This effectively protects the company's core technical parameters, product quality status, and production process information.

[0020] Furthermore, after the step of loading the dynamic test configuration file, and before starting the test, a time synchronization and verification step is also included: At system startup or before starting a new round of testing, attempt to establish a communication connection with at least one Network Time Protocol (NTP) server; Send a time query request to the network time protocol server and receive the current standard time returned by it; The local system clock is corrected using the received standard time, and the corrected local time is used as the base timestamp for this test session. After calibrating the local system clock, a hardware clock count value is immediately read from the trusted platform module chip on the host motherboard, and the hardware clock count value is bound to the calibrated local time as tamper-proof evidence of this time synchronization event, and recorded together in the operation log. The result of successful or failed time synchronization is written to the operation log. If time synchronization fails, a warning message will pop up in the graphical user interface, allowing the operator to choose to continue the test using the local system time, or to treat the time synchronization failure as a serious error and prevent the test process from starting.

[0021] By adopting the above technical solution and synchronizing time with an authoritative NTP server, a unified and reliable time benchmark is provided for the entire testing system. This ensures that the timestamps of all test events, log records, and result files are consistent and comparable globally, which is the cornerstone for achieving cross-device and cross-batch data correlation analysis and accurate traceability. The introduction of a time anchoring mechanism from a hardware trusted platform module establishes a non-repudiable and tamper-proof audit trail. The hardware counter of the TPM chip is independent of the operating system, and its count value is extremely difficult to be maliciously tampered with by software. Digitally binding and recording the software time obtained from NTP synchronization with this hardware counter value is equivalent to stamping a digital seal or time notarization on this time synchronization operation and all subsequent timestamps. In any post-audit, quality dispute, or legal evidence collection scenario, this record can provide strong evidence that the occurrence time of the test event has not been forged or tampered with.

[0022] Furthermore, this includes: when a user clicks the "Power Off Now" button, first interrupting all running test threads to ensure that all hardware interfaces are safely released and shut down; Before sending the safe shutdown command, the system checks whether a write operation to the flash memory chip on the PCB board is in progress. If a flash memory write operation is detected, it immediately sends an emergency stop write command to the PCB board and waits for the PCB board to return a write stop confirmation signal. After receiving the confirmation signal, the subsequent shutdown process is executed to prevent the flash memory chip data from being corrupted or becoming unusable due to a sudden power outage. Send a safe shutdown command to the operating system, triggering the operating system's standard shutdown procedure.

[0023] By adopting the above technical solutions, the one-click immediate shutdown function provides a fast, orderly, and safe exit path in emergencies. By interrupting threads, releasing resources, and then shutting down, it minimizes the risk of data loss, file system corruption, or operating system malfunctions that could result from forced power outages. The flash memory write status awareness and emergency stop protection mechanism provides proactive protection against the most dangerous operations in testing scenarios. During BIOS and EC firmware updates, power interruptions are a major cause of motherboard failure. Therefore, monitoring of this high-risk state is added at the system level, and upon triggering shutdown, it prioritizes secure communication with the controller on the PCB board, commanding it to place the flash memory operation into a recoverable and safe state. This provides a crucial last line of protection for expensive motherboards under test, effectively preventing permanent hardware damage caused by accidental shutdowns or misoperations, significantly reducing material loss risks and repair costs in the production testing phase, and improving the overall safety of testing operations.

[0024] Secondly, this application provides an intelligent PCB board function testing system.

[0025] A smart PCB board functional testing system includes: The configuration file loading module is used to receive test configuration instructions and load the dynamic test configuration file associated with the PCB board under test. The dynamic test configuration file defines the judgment conditions for multiple test items divided into the first test group and the second test group. A user interface rendering module is used to synchronously render and display a first test window and a second test window on a graphical user interface, wherein the first test window is configured to monitor and execute test items in the first test group, and the second test window is configured to monitor and execute test items in the second test group. The test scheduling and execution engine is used to initiate concurrent test execution for the first test group and update the execution results, actual measurement values ​​and time consumption information of each test item in real time in the first test window; The production line cycle time prediction and early warning module is used to analyze the execution time distribution of the completed test items in the first test group in real time, predict the remaining total time of the current test session based on historical data, and automatically generate and send an early warning signal to adjust the operation sequence of subsequent workstations on the production line when the predicted time exceeds the preset production line cycle time threshold. The collaborative trigger control module is used to detect the execution results of all test items in the first test group in real time, and automatically generate and trigger a collaborative start command when it is detected that the execution results of all test items in the first test group meet the preset pass conditions. The test scheduling and execution engine is also used to respond to the collaborative start command, initiate test execution for the second test group, and control the second test window to update the test progress and results of the second test group in real time.

[0026] By adopting the above technical solutions, the system's modular architecture clearly separates the responsibilities of configuration management, interface presentation, test scheduling, intelligent analysis, and process control, making the system easy to develop, maintain, and expand. The introduction of the production line cycle time prediction and early warning module gives the system the ability to transcend the boundaries of traditional testing equipment, making it a collaborative node capable of intelligent interaction with the upper-level production system. By predicting and warning of test delay risks in real time, the system can proactively participate in the dynamic optimization of production cycle time, helping the entire production line achieve a smoother and more efficient flow. The close integration of the dual-window visual interface and the collaborative triggering mechanism not only provides operators with an intuitive and efficient monitoring and control experience, but also achieves optimal scheduling of test resources and automated connection of test processes through precise state machine management in the background, achieving significant comprehensive benefits in improving single-station testing efficiency and ensuring the smoothness of the entire production line.

[0027] Thirdly, this application provides an electronic device.

[0028] An electronic device includes: a memory for storing executable instructions; A processor is configured to execute the executable instructions to implement the intelligent PCB board function detection method as described in claim 1. Attached Figure Description

[0029] Figure 1 This is a schematic diagram of the overall architecture of the intelligent PCB board functional testing system provided in this embodiment. Detailed Implementation

[0030] To make the objectives, technical solutions, and advantages of this invention clearer, the technical solutions of this invention will be clearly and completely described below with reference to the accompanying drawings. The described embodiments are part of this invention, but not all of it. Other embodiments that can be obtained by those skilled in the art based on the content of this invention without creative effort should all fall within the protection scope of this invention.

[0031] This application describes in detail a method for functional testing of intelligent PCB boards.

[0032] Example 1 The method described in this application operates on an industrial control host connected to the motherboard under test via a cable, and is executed by dedicated test software installed on the host. The connection between the industrial control host and the motherboard under test includes various physical interfaces, such as a universal serial bus, a Type-C interface, an audio input / output interface, and a serial communication interface, used to establish electrical connections for transmitting control commands, applying excitation signals, and acquiring response data.

[0033] Step S101: System preparation and loading of dynamic test configuration files.

[0034] After the test software starts, it first executes the initialization process. Initialization includes establishing the graphical interface framework, connecting to the local storage database, configuring network parameters, and attempting to establish a communication link with the upper-level Manufacturing Execution System (MES). The MES is an information system used to manage and monitor the manufacturing process. After initialization, the software waits for and receives configuration instructions to start the test. These configuration instructions can originate from the operator manually selecting a configuration file on the software interface, or they can be automatically triggered by scanning the product barcode on the motherboard under test. In another embodiment, the configuration instructions can also originate from a production work order containing specific product model information issued by the MES.

[0035] Based on the received configuration instructions, the system loads a dynamic test configuration file that strictly corresponds to the model of the motherboard under test from a preset storage path. The storage path can be the local hard drive directory of the industrial control host or a network shared folder. The configuration file is defined using a structured data format, such as JavaScript object notation, a lightweight data exchange format that is easy for humans to read and write, and also easy for machines to parse and generate. Alternatively, in another embodiment, Extensible Markup Language (XML) can be used, a markup language designed for transmitting and storing data.

[0036] The configuration file defines the complete test plan. It logically divides all required tests into two test groups: Test Group 1 and Test Group 2. This grouping is based on the functional attributes of the test items, hardware resource usage, and the sequential dependencies of the test logic. Test Group 1 typically includes tests verifying the motherboard's external interfaces and basic functions. In a specific configuration example, Test Group 1 might contain seven tests: product serial number scanning and automatic entry test, enumeration and data transmission test of various universal serial bus interfaces, verification of the Type-C interface's reversible plug-in identification and power transmission function, triggering and response test of all physical keys on the keyboard, on / off and image capture test of the built-in camera, physical link connectivity test of the wired network interface, and basic connectivity test of the audio input / output circuits. Test Group 2 typically includes tests for in-depth performance verification of the motherboard's core components, power management system, and advanced functions such as biometrics. In a specific configuration example, the second test group may include nine test items, namely: voltage and current characteristics test during battery charging, verification of basic input / output system firmware version, reading and verification of CPU model and operating frequency information, verification of double data rate memory capacity and operating frequency, fingerprint sensor input and matching accuracy test, high-fidelity audio recording quality and spectrum analysis, display backlight uniformity and dead pixel detection, wireless network card connection and data transmission rate test, and power consumption and heat dissipation performance test of the entire device under different loads. It should be emphasized that the specific number, content, and grouping method of the test items can be adjusted according to the actual product definition, and this invention is not limited to the specific example above.

[0037] The configuration file defines dynamically adjustable judgment conditions and execution parameters for each test item, decoupling the test logic from the program code. For test items with numerical output, such as testing voltage or current, the judgment conditions include the upper and lower bounds of the acceptable range, and a desired typical value can also be selectively configured. The upper bound defines the maximum allowable value within the acceptable range, and the lower bound defines the minimum allowable value. For test items with string output, such as checking version numbers, the judgment conditions mainly involve a specific string to be matched, and the matching rule can be specified as either exact match or inclusion. For test items that require checking externally generated files to determine the result, the judgment condition is a specific string that must be contained in the target file. Furthermore, the configuration file also defines the test execution mode associated with each test item. There are at least two test execution modes: command-line test mode and file inspection test mode. Command-line test mode refers to the test method that executes external diagnostic tool programs by calling the operating system command line. File inspection test mode refers to the test method that obtains test results by reading and parsing the contents of a specified file. The configuration file also specifies metadata information such as the paths to external tools required to execute the test, the list of command-line arguments to be passed when running the tools, the maximum allowed timeout threshold, and the target file path rules to be located when the test mode is file inspection. This highly configurable design means that when adapting to new motherboard models or adjusting test standards, only the configuration file needs to be updated; there is no need to modify or recompile the software, greatly improving the system's flexibility and maintainability.

[0038] Step S102: Synchronous rendering of the dual test window graphical interface and establishment of a reliable time base.

[0039] After successfully loading and parsing the configuration file, the system's user interface rendering module begins operation. On the main display device of the industrial control host, the module synchronously renders and displays two side-by-side, independently controlled, and visually distinct application windows, named the First Test Window and the Second Test Window, respectively. The First Test Window is used to monitor and execute the test items in the First Test Group. The Second Test Window is used to monitor and execute the test items in the Second Test Group.

[0040] The two windows maintain a high degree of consistency in layout and control composition. Their core component is a table view used to display and manage all test items within the same test group. The table typically contains the following columns: a sequence number column to display the sequential number of the test item; a test item column to describe the name or content of the test item; an upper limit value column to display the acceptable upper boundary value read from the configuration; a lower limit value column to display the acceptable lower boundary value read from the configuration; an actual value column to display the actual measured value obtained after test execution; a result column to display the result status after automatic system judgment; a detailed information column to display supplementary explanations of the test process or results; and a time consumption column to record the execution time of the test item. Below the table area of ​​each test window is a separate control panel. The control panel includes a "Start Test" button (usually green) to initiate group testing; a "Stop Test" button (usually red) for emergency stopping during testing; and a real-time updated statistics display area dynamically showing information such as the total number of test items in the group, the number that has passed, the number that has failed, and the number that has not yet started testing.

[0041] At the top of the graphical user interface is a global status bar. This bar continuously displays the current system time, the total time elapsed since the start of the current test session, and a summary of the overall test results, such as waiting, test in progress, all passed, and partial failure. At the bottom of the interface, a scrollable multi-line text box is typically reserved as a dedicated area for displaying system operation logs.

[0042] After the interface rendering is complete, the system automatically executes high-precision time synchronization and anti-tampering verification steps. This step aims to establish a unified, reliable, and auditable time base for the entire test session. The system attempts to establish a communication connection with at least one reliable Network Time Protocol (NTP) server. NTP is a protocol used to synchronize computer system time. The system sends a time query request to the server and receives the current standard time returned. Subsequently, the system uses this standard time to correct the local operating system clock of the industrial control host. After successful time correction, the system immediately reads a hardware clock count value from the Trusted Platform Module (TPM) chip integrated on the industrial control host motherboard. The TPM is a secure chip whose hardware clock counter operates independently of the operating system. The system strongly associates this hardware clock count value with the time just acquired from the NTP server, forming an inseparable time evidence pair, and records it in the operation log. Thereafter, the timestamps of all test events are based on this unified time base. If time synchronization fails, the system records a warning log and displays a prompt on the interface, allowing the operator to choose to continue using local time or abort the process.

[0043] Step S103: Production information binding and automated error prevention verification.

[0044] Before officially starting the test, this test session must be bound to unique product and production process information. The system continuously obtains key test binding information from the Manufacturing Execution System or receives it manually entered by the operator through the interface. The test binding information includes at least the product serial number, machine information, and work order information. It can also be extended to part number, customer name, machine number, operator ID, etc.

[0045] A common implementation involves an operator scanning the product barcode on the motherboard with a barcode scanner, and the system automatically fills in the serial number into the input box. Next, the system automatically calls the Manufacturing Execution System's (MES) Application Programming Interface (API), sending a query request containing the product serial number. An API is a set of rules defining the interactions between software components. The MES returns a response message containing information such as the machine model and work order. The system parses the response and automatically populates the interface.

[0046] Simultaneously, the system performs automated error prevention checks. It verifies the checksum of the product serial number and checks if the model name matches the name of the currently loaded dynamic test configuration file. If a check fails, the system displays a modal warning window covering the entire main window and automatically disables all test control buttons until the operator re-enters or confirms the information. This forced blocking effectively prevents configuration errors. All successfully verified binding information is stored in association with a unique identifier for this test session.

[0047] Step S104: Start the concurrent test execution for the first test group.

[0048] The operator clicks the "Start Test" button in the first test window. The test scheduling and execution engine initiates the execution of tests for the first test group. Execution can be sequential or concurrent to optimize resource utilization.

[0049] Taking the camera on / off test as an example, the system parses its test mode as a command-line test mode. The engine calls the command-line executor, passing the external program path, command-line arguments, timeout threshold, and a regular expression for the expected output. A regular expression is a pattern used to match combinations of characters in a string. The engine captures the standard output and standard error streams of the external program and performs matching analysis based on the regular expression to obtain the actual measurement value. Subsequently, the system reads the judgment threshold from the configuration, compares it with the actual measurement value, generates a deterministic judgment result, and updates the interface in real time.

[0050] While the first test group is executing, the production line cycle time prediction and early warning module is activated. It analyzes the execution time distribution of completed test items in real time and predicts the remaining total time of the current test session based on historical data. When the predicted time exceeds the preset production line cycle time threshold, an early warning signal is automatically generated and sent to the manufacturing execution system to adjust the operation sequence of subsequent workstations on the production line. This enables the test workstations to proactively coordinate with production and avoid production line congestion.

[0051] Step S105: Testing of integrated acoustic environment perception.

[0052] When performing audio-related tests, the system integrates acoustic environment awareness. During the execution of the external executable program, a specific frequency and pattern audio verification signal is synchronously output to the environment via the sound card, and echo signals are monitored through a microphone circuit connected to the audio input interface on the PCB board. By comparing the frequency attenuation and phase delay of the output and received signals, the acoustic background noise level of the current test environment is dynamically assessed. If the background noise level exceeds a preset threshold, the final judgment result of the current test item is marked as an environmental interference warning, along with noise level information. This provides an environmental attribution basis for audio test failures.

[0053] Step S106: Automatic boundary value verification and collaborative triggering control.

[0054] After all items in the first test group have been executed, the collaborative trigger control module performs a status check. The preset pass condition is that the result status indicators for all items are "pass" and all actual measurement values ​​have been acquired. The result status indicators are graphic elements that clearly indicate whether the item has passed, failed, or not executed, using color or text.

[0055] During the traversal check, if the actual measured value of a test item falls exactly on the boundary value of its judgment threshold, an additional boundary value verification test is initiated. The boundary value verification test re-acquires the actual measured value by improving sampling accuracy, extending sampling time, or using a higher-precision measurement command, and uses the verified value as the final judgment basis. This enhances the scientific rigor of the judgment.

[0056] If all pass conditions are met, the monitoring thread or the main scheduling thread creates an internal system event, "First group of tests completed and passed," as a trigger signal. This event calls the initialization entry function of the test executor for the second test group, thereby generating the collaborative start instruction. If there are failures or values ​​not obtained, the collaborative start instruction will not be generated, and the second test window will remain in a waiting state.

[0057] Step S107: The second test group automatically executes and closes the data loop.

[0058] In response to the collaborative start command, the test scheduling and execution engine automatically initiates the execution of tests for the second test group and updates the test progress and results in real time in the second test window. This achieves automated workflow integration.

[0059] Throughout the test execution process, the system continuously acquires or receives manually input test binding information from the manufacturing execution system. After all test items are completed, the test result dataset, containing the final results of all test items, actual measured values, test binding information, and execution timestamps of each test item, is automatically uploaded to the designated remote server via the communication interface.

[0060] Step S108: Securely encrypt and upload the test data.

[0061] In the automatic upload step of the test result dataset, the system first serializes it into a structured data file according to a preset format. The format can be JavaScript object notation, Extensible Markup Language (XML), comma-separated value files, or plain text files. During serialization, a preset symmetric encryption algorithm and key are used to encrypt sensitive data fields containing actual measurement values, product serial numbers, and operator identifiers. The encrypted ciphertext data replaces the original field values, and the initialization vector used for encryption is stored in the file as a non-sensitive field. This ensures that only the server with the corresponding decryption key can fully read the test results. Then, the file is uploaded to a specified directory on the remote server via a file transfer protocol, a secure file transfer protocol, or a file upload interface based on Hypertext Transfer Protocol (HTTP). The interface updates the progress in real time during the upload process. After the upload, the operation log records the event.

[0062] Step S109: Intelligent management of operation logs.

[0063] Throughout the testing process, the system records all operational events, test status changes, network communication results, and anomaly information in a structured log format in the local operation log storage module. The system periodically performs semantic analysis on log entries to identify frequently occurring combinations of specific errors or warnings. When the frequency exceeds a preset threshold, a preliminary diagnostic report is automatically generated and pushed to the top of the log display area as a high-level warning. This helps in quickly locating problems.

[0064] Step S110: Safety shutdown control.

[0065] The graphical user interface also provides safety control functions. A globally visible "Immediate Power Off" button is provided on the interface, clearly distinguishable from normal test control buttons by color or location. When a user clicks this button, all currently executing test threads are first interrupted to ensure all hardware interfaces are safely released. Before sending the safe power-off command, the system checks whether a write operation to the PCB board's flash memory chip is currently in progress. If a write operation is detected, a specific command to urgently stop the write operation is immediately sent to the PCB board, and the system waits for a write abort confirmation signal from the PCB board. After receiving confirmation, the subsequent power-off process is executed to prevent damage to the flash memory chip due to a sudden power outage. Then, a safe power-off command is sent to the operating system, triggering the standard power-off process.

[0066] Example 2 This embodiment shares the same core process and architecture as Embodiment 1, with the main difference being the definition of the dynamic test configuration file and the extended implementation of specific test functions.

[0067] In one configuration of this embodiment, the dynamic test configuration file adopts the Extensible Markup Language (EXPLAIN) format. The test items in the first test group are configured to verify the PCB board's barcode, serial number, USB interface, Type-C interface, keyboard keys, and camera on / off function. The test items in the second test group are configured to verify the same PCB board's battery charging function, Basic Input / Output System (BIOS) version, CPU information, Double Data Rate (DDR) memory information, fingerprint recognition function, and audio input function. The test items in the first and second test groups are functionally independent but share the same test binding information and data upload channel.

[0068] In another configuration variant, dynamic test profiles can define environment-dependent tests. For example, test items in the first test group are configured to perform tests that must be conducted under specific ambient lighting conditions, such as no direct, strong light. Test items in the second test group are configured to perform tests that must be conducted within a specific environmental electromagnetic field background noise threshold. The system monitors current environmental parameters using external light and electromagnetic field sensors connected to the host. Real-time light intensity readings are displayed only in specific areas of the first test window, and real-time electromagnetic field intensity readings are displayed in specific areas of the second test window. When a reading exceeds the preset environmental threshold for the corresponding test group, the start test button for that test group is automatically disabled. This ensures that tests are performed in a compliant environment.

[0069] In one specific implementation of the command-line test mode, the external executable program is a dedicated diagnostic tool used to communicate with embedded controllers, power management chips, sensors, or interface chips on the PCB board. Command-line arguments contain a sequence of instructions specifying the target hardware port, setting the test mode, and reading specific register addresses. Regular expressions are configured to extract numerical values ​​or strings representing voltage, current, frequency, capacity, version number, or status identifiers from the tool's output text.

[0070] Furthermore, during the execution of the dedicated diagnostic tool, the system sends control commands to a miniature programmable load module connected to the PCB board's power supply line via the host's general purpose input / output interface or serial bus interface. These control commands simulate dynamically changing load currents when testing battery charging or power management functions, thereby testing the dynamic response capability of the PCB board's power management unit under load transient conditions. This dynamic response characteristic curve is then used as part of the actual measured values ​​of the test item for evaluation. This achieves dynamic performance testing.

[0071] In the file inspection test mode, the target inspection file is a data file generated and written to a specified directory by the functional module under test on the PCB board, independent test firmware, or the external executable program in previous test steps. The file content parsing script is configured to parse binary format log files, plain text format report files, or structured data format configuration files to obtain key fields characterizing the test results.

[0072] Example 3 Furthermore, in the collaborative trigger control, the step of periodically polling the first test window status can be triggered by the main scheduling thread creating an independent monitoring thread after at least one test item in the first test group has started execution. The monitoring thread queries the result status of all test items belonging to the first test group at preset time intervals until all test items have completed execution.

[0073] In an enhanced monitoring design, a separate monitoring thread, while polling the query result status, simultaneously uses a dedicated image acquisition thread to continuously capture screen images of the main display running the graphical user interface at low frame rate and low resolution. The captured images are then processed by optical character recognition (OCR), a technique that converts text in an image into machine-coded text. The system cross-compares the recognized text with the status text of each test item read directly from memory. If discrepancies occur consecutively within a preset number of polling iterations, a graphical user interface display anomaly or process freeze is assumed, automatically triggering a soft reset operation for the first test group's test processes. This enhances the system's self-healing capabilities.

[0074] The internal system event of "the first test group is completed and passed" can be transmitted in various ways, such as inter-process communication mechanisms, inter-thread message queues, or global shared memory flags, from the execution process or thread of the first test group to the execution process or thread of the second test group, thereby achieving loose coupling and collaboration between different test execution entities.

[0075] In interacting with the Manufacturing Execution System (MES), its application programming interface (API) can be an HTTP interface based on a representational state transition architecture. Representational state transition is a software architectural style. The query request message is a GET request containing a product serial number parameter. The response message is an HTTP response containing data in JavaScript object notation or Extensible Markup Language (EXPLAIN) format.

[0076] In an intelligent interactive design, before sending a query request message to the Manufacturing Execution System (MES) server, the system queries its local cache for the product serial number's test failure history over the past 24 hours. If the number of failures exceeds a preset threshold, a high-priority check flag is added to the query request message. Upon receiving a request with this flag, the MES server appends a special prompt message to its response message. This prompt message is displayed prominently in the graphical user interface to remind the operator to focus on checking this board.

[0077] Information manually entered by the operator can also be obtained by scanning product barcodes, reading RFID tags, or decoding 1D or 2D barcodes. The system automatically extracts the product serial number or model information from the scanned string and fills it into the corresponding input controls.

[0078] Regarding the integrity verification of uploaded data, the preset file naming rule can be the product serial number. Test completed Timestamp The system identifier is used to specify the file extension, where the test completion timestamp is in the format of year-end-month-day-hour-minute-second. Before uploading a structured data file, the system calculates the file's hash value and writes it to a separate field in the file content. After a successful file upload, the system immediately downloads a small fragment or the entire uploaded file from the remote server, recalculates its hash value, and compares it with the hash value recorded locally. If they do not match, it is determined that data corruption occurred during the upload process, and a retransmission is automatically triggered until the verification passes or the maximum number of retries is reached. This ensures end-to-end data integrity.

[0079] The path structure of the specified directory on the remote server can be the base path and the test completion date. The test completion date is obtained by parsing the test completion timestamp field from the test result dataset. After a file upload is successful, the asynchronous file upload task can also synchronously send the upload success confirmation information and the server file storage path back to the manufacturing execution system via a callback interface or message queue, so as to update the test completion status of the corresponding work order in the manufacturing execution system.

[0080] In terms of operation log management, log levels should include at least four levels: information, warning, error, and success. The associated context data is dictionary data in key-value pair format, containing exception stack trace information captured when an exception occurs.

[0081] The system can integrate a lightweight speech synthesis module. When the system detects an entry with an error level in the log, and the error entry contains preset keywords such as fatal, hardware failure, or communication interruption, it will automatically call the speech synthesis module to read out the core content of the error entry in a voice broadcast using the operator's preset language and intonation, and continue broadcasting until the operator manually confirms the error information. This provides an auditory alarm channel.

[0082] The operation log can be output to the graphical user interface in real time via a scrollable multi-line text box widget. The system appends newly generated log entries to the end of the text box and automatically scrolls to the latest line. Simultaneously, users can use the search function provided in the text box to enter keywords to filter and locate log entries containing specific information for quick problem diagnosis.

[0083] Reference Figure 1 This application also provides an intelligent PCB board functional testing system. The system includes: The configuration file loading module is used to receive test configuration instructions and load dynamic test configuration files.

[0084] The user interface rendering module is used to synchronously render and display the first test window and the second test window on the graphical user interface.

[0085] The test scheduling and execution engine is used to initiate the execution of tests for the first test group and update the interface information in real time.

[0086] The production line cycle time prediction and early warning module is used to analyze the execution time of completed items in the first test group in real time, predict the remaining total time based on historical data, and automatically generate and send an early warning signal when the prediction exceeds the threshold.

[0087] The collaborative trigger control module is used to detect the results of all items in the first test group in real time, and automatically generate and trigger the collaborative start command when the conditions are met.

[0088] The test scheduling and execution engine is also used to respond to collaborative start commands and initiate test execution for the second test group.

[0089] This embodiment also provides an electronic device, including a memory and a processor. The memory is used to store executable instructions, and the processor is used to execute the executable instructions to implement the above-described intelligent PCB board function detection method.

[0090] The above description is merely a preferred embodiment of the present invention and is not intended to limit the scope of protection of the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention. For example, the test group can be divided into more groups as needed and a multi-level trigger chain can be established; environmental perception can be extended to multiple sensors such as temperature and vibration; the encryption algorithm can select the national cryptographic algorithm according to security requirements; the communication interface can be adapted to multiple types such as Ethernet and PCIe. The system and method of the present invention are also applicable to the functional testing of various complex electronic products.

Claims

1. A method for functional testing of an intelligent PCB board, characterized in that, Includes the following steps: Receive test configuration instructions and load the dynamic test configuration file associated with the PCB board under test. The dynamic test configuration file defines the judgment conditions for multiple test items divided into the first test group and the second test group. A first test window and a second test window are synchronously rendered and displayed on a graphical user interface, wherein the first test window is used to monitor and execute test items in the first test group, and the second test window is used to monitor and execute test items in the second test group; Initiate concurrent test execution for the first test group, and update the execution results, actual measurement values, and time consumption information of each test item in real time in the first test window; The system analyzes the execution time distribution of completed test items in the first test group in real time, and predicts the remaining total time of the current test session based on historical data. When the predicted time exceeds the preset production line cycle time threshold, it automatically generates and sends an early warning signal to adjust the operation sequence of subsequent workstations on the production line. The execution results of all test items in the first test group are detected in real time, and a collaborative start command is automatically generated and triggered when the execution results of all test items in the first test group meet the preset pass conditions. Based on the collaborative start command, the test execution for the second test group is initiated, and the test progress and results of the second test group are updated in real time in the second test window.

2. The method according to claim 1, characterized in that, The step of initiating test execution for the first test group includes: Parse the test modes defined for each test item in the dynamic test configuration file, wherein the test modes include at least command-line test mode and file inspection test mode; When the test mode is command-line test mode, a command-line executor adapted to the current operating system is invoked. A predefined regular expression for the external executable program path, command-line parameters, timeout threshold, and expected output result is passed to the command-line executor. The standard output stream and standard error stream during the execution of the external executable program are captured. The text content of the standard output stream and / or standard error stream is matched and analyzed according to the regular expression to obtain the actual measurement value of the test item. When the test mode is the file inspection test mode, the target inspection file is located according to the predefined file path rules, and the complete content or specific data blocks of the target inspection file are read. By calling the preset file content parsing script or library, the read content is subjected to keyword retrieval, numerical extraction or structured data comparison to obtain the actual measurement value of the test item.

3. The method according to claim 2, characterized in that, The step of initiating test execution for the first test group includes: During the execution of the external executable program, an audio verification signal of a specific frequency and mode is output to the test environment. The echo signal is monitored by the audio acquisition circuit built into the PCB board under test. By comparing the frequency attenuation and phase delay of the output audio verification signal with the received echo signal, the acoustic background noise level of the current test environment is dynamically evaluated. If the background noise level exceeds the preset threshold, the final judgment result of the current test item is marked as "environmental interference warning" and noise level information is added.

4. The method according to claim 2, characterized in that, The step of updating the execution result of each test item in real time in the first test window includes: The judgment threshold configured for the current test item is read from the dynamic test configuration file. The judgment threshold includes any one or more of the following: numerical upper and lower boundary values, string expected matching values, specific strings that the file content must contain, or process identifiers that the process must exist. The actual measured value of the obtained test item is compared with the judgment threshold, and a deterministic judgment result is generated according to the preset judgment logic. The judgment logic is as follows: if the actual measured value is a numerical value, it is determined whether it falls within the closed interval formed by the upper boundary value and the lower boundary value; if the actual measured value is a string, it is determined whether it is completely consistent with the expected matching value or matches the specified pattern; if the test mode is a file inspection mode, it is determined whether the content of the target inspection file contains the specific string.

5. The method according to claim 1, characterized in that, The step of real-time detection of the execution results of all test items in the first test group, and automatic generation of a collaborative start command when all test items meet the preset pass conditions, includes: After the last test item in the first test group is completed, or the first test window status monitoring thread periodically polls, the execution result status indicators of all test items in the first test group are traversed and checked. During the traversal inspection, if it is found that the actual measurement value of a certain test item falls exactly on the boundary value of its judgment threshold, an additional boundary value verification test is initiated. The boundary value verification test re-acquires the actual measurement value of the test item by improving the sampling accuracy, extending the sampling time, or using a higher precision measurement command, and uses the actual measurement value obtained after verification as the final judgment basis. If and only if the pass condition is met, the first test window status monitoring thread or the main scheduling thread creates an internal system event "first group of tests completed and passed" as a trigger signal, calls the test executor initialization entry function of the second test group, and thus generates the collaborative start instruction; If at least one execution result status indicator in the first test group is in failure, or if an actual measurement value is not successfully obtained, the collaborative start instruction will not be generated, and the second test window will remain in a waiting state.

6. The method according to claim 1, characterized in that, It also includes the following steps: The steps for automatically uploading the test result dataset to a specified remote server include: After the test is completed and the final test result dataset is generated, the system automatically starts an asynchronous file upload task; The asynchronous file upload task first serializes the test result dataset into a structured data file according to a preset format. When serializing the structured data file, a preset symmetric encryption algorithm and key are used to encrypt sensitive data fields containing the actual measurement value, product serial number and operator identifier, and the encrypted ciphertext data replaces the original field values. At the same time, the initial vector used for encryption is stored in the file as a non-sensitive field, so that only the server with the corresponding decryption key can read the test results completely. The asynchronous file upload task uploads the structured data file to a pre-configured remote server directory through a file transfer protocol, a secure file transfer protocol, or a file upload interface based on the hypertext transfer protocol. During the upload process, the upload progress percentage and status text are updated in real time on the graphical user interface. After the upload is completed, the operation log records the upload success or failure event and the corresponding server path.

7. The method according to claim 1, characterized in that, Following the step of loading the dynamic test configuration file, and before starting the test, a time synchronization and verification step is also included: At system startup or before starting a new round of testing, attempt to establish a communication connection with at least one Network Time Protocol (NTP) server; Send a time query request to the network time protocol server and receive the current standard time returned by it; The local system clock is corrected using the received standard time, and the corrected local time is used as the base timestamp for this test session. After calibrating the local system clock, a hardware clock count value is immediately read from the trusted platform module chip on the host motherboard, and the hardware clock count value is bound to the calibrated local time as tamper-proof evidence of this time synchronization event, and recorded together in the operation log. The result of successful or failed time synchronization is written to the operation log. If time synchronization fails, a warning message will pop up in the graphical user interface, allowing the operator to choose to continue the test using the local system time, or to treat the time synchronization failure as a serious error and prevent the test process from starting.

8. The method according to claim 1, characterized in that, include: When a user clicks the "Power Off Now" button, all running test threads are first interrupted to ensure that all hardware interfaces are safely released and shut down. Before sending the safe shutdown command, the system checks whether a write operation to the flash memory chip on the PCB board is in progress. If a flash memory write operation is detected, it immediately sends an emergency stop write command to the PCB board and waits for the PCB board to return a write stop confirmation signal. After receiving the confirmation signal, the subsequent shutdown process is executed to prevent the flash memory chip data from being corrupted or becoming unusable due to a sudden power outage. Send a safe shutdown command to the operating system, triggering the operating system's standard shutdown procedure.

9. An intelligent PCB board functional testing system, characterized in that, include: The configuration file loading module is used to receive test configuration instructions and load the dynamic test configuration file associated with the PCB board under test. The dynamic test configuration file defines the judgment conditions for multiple test items divided into the first test group and the second test group. A user interface rendering module is used to synchronously render and display a first test window and a second test window on a graphical user interface, wherein the first test window is configured to monitor and execute test items in the first test group, and the second test window is configured to monitor and execute test items in the second test group. The test scheduling and execution engine is used to initiate concurrent test execution for the first test group and update the execution results, actual measurement values ​​and time consumption information of each test item in real time in the first test window; The production line cycle time prediction and early warning module is used to analyze the execution time distribution of the completed test items in the first test group in real time, predict the remaining total time of the current test session based on historical data, and automatically generate and send an early warning signal to adjust the operation sequence of subsequent workstations on the production line when the predicted time exceeds the preset production line cycle time threshold. The collaborative trigger control module is used to detect the execution results of all test items in the first test group in real time, and automatically generate and trigger a collaborative start command when it is detected that the execution results of all test items in the first test group meet the preset pass conditions. The test scheduling and execution engine is also used to respond to the collaborative start command, initiate test execution for the second test group, and control the second test window to update the test progress and results of the second test group in real time.

10. An electronic device, characterized in that, include: Memory, used to store executable instructions; A processor is configured to execute the executable instructions to implement the intelligent PCB board function detection method as described in claim 1.

Images