A scheduling method of general test instruments in a flexible manufacturing automatic test system

Abstract

The application discloses a scheduling method of a general test instrument in a flexible manufacturing automatic test system. The application provides a dynamically adjustable expected delay time benchmark for each test item by pre-configuring a delay time matrix recording delay time information of different test items under different signal transmission paths; on the basis, a parallel test sequence is generated combining the dependency relationship and resource occupation relationship among the test items, resource conflicts are avoided and the parallel execution of the test items meeting the dependency relationship is realized, so that the dynamic self-adaptive adjustment of the test sequence is realized in the case that test time fluctuation is caused by dynamic change of test parameters, the utilization rate of test resources is improved, the overall test time is shortened, and the stability and scheduling flexibility of the system are enhanced.

Description

Technical Field

[0001] This invention relates to the technical field of automated testing systems for flexible manufacturing, and specifically to a scheduling method for general testing instruments in automated testing systems for flexible manufacturing. Background Technology

[0002] Flexible Manufacturing Systems (FMS) are automated manufacturing systems designed for multi-variety, small-batch production models. Their high quality, high efficiency, and high flexibility have attracted significant attention and research from the academic community. The scheduling problem in FMS involves the rational and efficient allocation of a set of shared resources within a specified timeframe to achieve certain performance indicators while completing production tasks, ultimately aiming to improve enterprise production efficiency. The scheduling problem in FMS has been proven to be an NP (Non-deterministic Polynomial) problem, often proving difficult to solve when the scheduling scale is large.

[0003] An automated test system refers to a system that can automatically complete the testing of a target object and output the test results in an appropriate manner with little or no human intervention. In the early stages of research and development and during large-scale mass production, extensive and comprehensive electrical performance testing is essential. With the rapid development of modern science and technology, the complexity of products under test (DUTs) and general measuring instruments is increasing. The high complexity and numerous performance test items of DUTs lead to long testing times, high test system costs, limited testing efficiency, and scarce test instrument and equipment resources, which have become bottlenecks in the production and testing of multi-channel components.

[0004] In related technologies, when using general-purpose instruments to conduct parallel testing of multiple items in a flexible manufacturing automated testing system, the test time fluctuates due to the dynamic changes in test parameters. The scheduling methods of related technologies are difficult to achieve dynamic parallel scheduling of test items while avoiding resource conflicts. Therefore, there are technical problems of rigid scheduling and low resource utilization. Summary of the Invention

[0005] The technical problem this invention aims to solve is that, in related technologies, when using general-purpose instruments for parallel testing of multiple items in an automated testing system for flexible manufacturing, the dynamic changes in test parameters cause fluctuations in test time. The scheduling methods of these technologies struggle to achieve dynamic parallel scheduling of test items while avoiding resource conflicts, resulting in rigid scheduling and low resource utilization. The purpose is to provide a scheduling method for general-purpose testing instruments in an automated testing system for flexible manufacturing, thereby solving the problems of rigid scheduling and low resource utilization.

[0006] This invention is achieved through the following technical solution:

[0007] In a first aspect, the present invention provides a scheduling method for general testing instruments in a flexible manufacturing automatic testing system. The flexible manufacturing automatic testing system includes a control computer configured with a flexible scheduling software platform. The flexible scheduling software platform encapsulates general testing instruments, radio frequency routing allocation devices, and samples under test into independent and parallel channels, and realizes status interaction through an application programming interface.

[0008] The method includes:

[0009] A test task is obtained for the sample to be tested; wherein the test task includes multiple test items; wherein each test item is associated with the required test resources and the dependencies between it and other test items;

[0010] Read the pre-configured delay time matrix; wherein, the delay time matrix records the delay time information of different test items under different signal transmission paths;

[0011] For each test item, the corresponding expected delay time is determined based on its associated test resources, signal transmission path, and delay time information recorded in the delay time matrix.

[0012] Based on the expected latency of each test item, the dependencies between test items, and the resource occupancy relationships between test items, a parallel test sequence is generated so that test items that do not have resource conflicts and satisfy the dependencies are executed in parallel.

[0013] Tests are executed according to the control of test resources in the parallel test sequence.

[0014] Furthermore, the step of obtaining the test sample to be tested includes:

[0015] Receive the sample identifier and test parameters input by the user;

[0016] Based on the identifier of the sample to be tested, determine multiple test items to be executed from a predefined set of test items;

[0017] Based on the predefined resource mapping relationship, the test resources associated with each test project are determined, and the dependencies and parameterized constraints between test projects that have resource competition are identified based on the parameters to be tested.

[0018] Further, the step of reading the pre-configured delay time matrix includes:

[0019] Read the delay time matrix pre-configured in the extended configuration file; wherein the delay time matrix includes a test device submatrix, a test link submatrix, and a general test instrument submatrix; wherein each submatrix is ​​constructed with the input end of the signal transmission path as the row and the output end as the column, and each submatrix records at least the typical value of the delay time under the corresponding signal transmission path; wherein the delay time information of the delay time matrix for different test items and different signal transmission paths is the delay time information of the corresponding signal transmission path of each submatrix.

[0020] Furthermore, the step of determining the corresponding expected delay time for each test item based on its associated test resources, signal transmission path, and delay time information recorded in the delay time matrix includes:

[0021] For each test item, based on its associated test resources and signal transmission path, the delay time information corresponding to the signal transmission path is obtained from the test device submatrix, test link submatrix, and general test instrument submatrix, respectively.

[0022] The delay time information of each submatrix is ​​combined and calculated to obtain the expected delay time of the test item under the corresponding signal transmission path.

[0023] Furthermore, the step of combining and calculating the delay time information of each acquired sub-matrix to obtain the expected delay time of the test item under the corresponding signal transmission path includes:

[0024] The delay time information of each submatrix is ​​sequentially flattened, processed by generating a Cartesian product grid, and added element by element to obtain the total link delay time of the signal transmission path, and the total link delay time is used as the expected delay time of the test item.

[0025] Furthermore, the step of generating a parallel test sequence based on the expected latency of each test item, the dependencies between test items, and the resource occupancy relationships between test items, so that test items without resource conflicts and satisfying dependencies are executed in parallel, includes:

[0026] Using the expected delay time of each test item as the job duration, the test items are initially sorted using the shortest job priority strategy to generate an initial test sequence;

[0027] Based on the dependencies between test items and the occupancy of test resources, and combined with the channel status information obtained through the application programming interface, a priority value is assigned to each test item; wherein, the channel status information includes the real-time availability status of general test instruments, RF routing allocation devices, and the sample under test;

[0028] The initial test sequence, the priority values ​​of each test item, and the dependencies between test items are taken as input. The heterogeneous earliest completion time algorithm is used for iterative optimization to generate a parallel test sequence. Each parallel execution unit in the parallel test sequence includes a set of test items that do not have resource conflicts and satisfy the dependencies. The parallel execution units are sorted according to the expected latency and priority values ​​of the test items.

[0029] Further, the step of controlling test resources to execute tests according to the parallel test sequence includes:

[0030] According to the timing of the parallel test sequence, control commands are sent to the corresponding channels through the application programming interface to drive the general test instrument to generate test stimuli, control the RF routing and distribution device to switch signal paths, and obtain the test response of the sample under test.

[0031] During the test, the device status information of each channel is obtained in real time through the application programming interface.

[0032] By comparing the acquired device status information with the planned parallel test sequence, the execution of the test task is dynamically adjusted when an abnormal status or timing deviation is detected.

[0033] Furthermore, the method also includes:

[0034] After completing the tests according to the parallel test sequence, obtain the actual test time of each test item under the corresponding signal transmission path;

[0035] The actual test time is written back to the position of the delay time information corresponding to the signal transmission path in the delay time matrix in the extended configuration file, so as to dynamically update the delay time matrix.

[0036] Secondly, the present invention provides an automated testing system for flexible manufacturing, comprising:

[0037] A control computer is configured with a flexible scheduling software platform; wherein the flexible scheduling software platform is configured to execute the scheduling method described above.

[0038] One or more general-purpose testing instruments are communicatively connected to the control computer;

[0039] The radio frequency routing and distribution device is communicatively connected to the control computer and connected to the general-purpose test instrument and the sample under test, respectively, and is used to switch the test signal path under the control of the control computer.

[0040] The flexible scheduling software platform encapsulates the general-purpose test instrument, radio frequency routing allocation device, and test sample into independent and parallel channels, and realizes state interaction through application programming interface.

[0041] Thirdly, the present invention provides an electronic device, comprising: a memory, and one or more processors communicatively connected to the memory; the memory stores instructions executable by the one or more processors, the instructions being executed by the one or more processors to cause the one or more processors to implement the method described above.

[0042] Compared with the prior art, the present invention has the following advantages and beneficial effects:

[0043] The scheduling method provided by this invention solves the problems of data sharing and resource allocation conflicts in parallel testing scenarios by encapsulating general-purpose test instruments, RF routing allocation devices, and test samples into independent and parallel operating channels and enabling state interaction. By pre-configuring a delay time matrix that records the delay time information of different test items under different signal transmission paths, a dynamically adjustable expected delay time benchmark is provided for each test item. Based on this, a parallel test sequence is generated by combining the dependencies and resource occupancy relationships between test items, avoiding resource conflicts and enabling parallel execution of test items that satisfy dependencies. Thus, even when dynamic changes in test parameters cause fluctuations in test time, the test sequence can be dynamically and adaptively adjusted, improving the utilization rate of test resources, shortening the overall test time, and enhancing the stability and scheduling flexibility of the system. Attached Figure Description

[0044] To more clearly illustrate the technical solutions of the exemplary embodiments of the present invention, the accompanying drawings used in the embodiments will be briefly described below. It should be understood that the following drawings only show some embodiments of the present invention and should not be considered as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort. In the drawings:

[0045] Figure 1 A flowchart illustrating a scheduling method for general-purpose test instruments in an automated testing system for flexible manufacturing, as provided in the embodiments of this specification.

[0046] Figure 2 This is a schematic block diagram of an automated testing system for flexible manufacturing provided in the embodiments of this specification;

[0047] Figure 3 This is a block diagram illustrating the structural principle of the flexible scheduling software provided in the embodiments of this specification.

[0048] Figure 4 This is a system flowchart provided for the embodiments in this specification. Detailed Implementation

[0049] To make the objectives, technical solutions, and advantages of the present invention clearer, the present invention will be further described in detail below with reference to the embodiments and accompanying drawings. The illustrative embodiments and descriptions of the present invention are only used to explain the present invention and are not intended to limit the present invention.

[0050] In the field of automated testing systems for flexible manufacturing, general-purpose test instruments (independent signal sources, spectrum analyzers, vector network analyzers, etc.) are widely deployed due to their comprehensive functions, reliable performance, and large stock in various industries' testing processes. A typical automated testing system for flexible manufacturing often consists of a control computer, multiple general-purpose test instruments, an RF routing and distribution device for flexibly switching signal paths, and multiple samples under test. In this system environment, the core requirement for achieving efficient testing lies in the parallel scheduling of multiple test items to improve the utilization rate of expensive instrument resources and the overall test throughput.

[0051] The relevant technologies employ scheduling methods based on static or quasi-static planning. In this method, the test sequence is generated and fixed once before the task begins. The system executes tests based on this fixed sequence, and the allocation of test instruments and RF routes is determined during the planning phase. However, in actual production testing, especially in multi-variety, small-batch modes, the test parameters of the samples under test (e.g., the number of scan levels, signal amplitude, etc.) often need to be dynamically adjusted according to different test stages or sample types. Such parameter changes directly lead to significant fluctuations in the execution time of individual test items.

[0052] Because static scheduling sequences cannot perceive and adapt to real-time changes in execution time, their pre-planned resource usage periods are prone to deviating from actual needs. As a result, on the one hand, some test instruments may remain idle during the planned time period while waiting for preceding tasks, leading to reduced utilization. On the other hand, multiple test items may compete for the same instrument or RF path during the same time period, causing resource conflicts and system deadlocks. To avoid conflicts, the system is often forced to interrupt, waiting for manual rescheduling of the global test sequence. This not only severely reduces testing efficiency but also significantly diminishes the advantages of flexibility and parallelism.

[0053] The root cause of the above problems lies in the fact that dynamic changes in test parameters lead to uncertain test times, while existing scheduling methods lack the data foundation to dynamically reflect these changes and the decision-making mechanism to adjust scheduling strategies in real time. Specifically, the time of a test item depends not only on the test content itself but also on factors such as signal transmission paths, instrument response times, and RF routing switching delays. These factors collectively constitute the actual execution time of the test item, but related technologies have not structurally incorporated this information into scheduling decisions, resulting in a disconnect between the scheduling scheme and the actual situation.

[0054] The core technical problem arising from this is that in the scenario of using general-purpose instruments to conduct parallel testing of multiple items in a flexible manufacturing automated testing system, the test time fluctuates due to the dynamic changes in test parameters. The scheduling methods of related technologies are difficult to achieve dynamic parallel scheduling of test items while avoiding resource conflicts. Therefore, there are technical problems of rigid scheduling and low resource utilization.

[0055] like Figure 1 As shown, this embodiment provides a scheduling method for general-purpose test instruments in a flexible manufacturing automatic testing system. The flexible manufacturing automatic testing system includes a control computer configured with a flexible scheduling software platform. The flexible scheduling software platform encapsulates general-purpose test instruments, radio frequency routing allocation devices, and samples under test into independent and parallel-running channels, and realizes status interaction through an application programming interface.

[0056] The method includes:

[0057] Step S10: Obtain the test task of the sample to be tested; wherein, the test task includes multiple test items; wherein, each test item is associated with the required test resources and the dependencies between it and other test items.

[0058] In this embodiment, the flexible scheduling software platform can use a microservice architecture to construct the general-purpose test instruments, RF routing and allocation devices, and test samples in the system as independent and parallel logical channels. Each channel corresponds to a physical device or functional unit. Channels do not directly share memory or data, but instead transmit time synchronization information and device status information through a distributed message queue (e.g., RabbitMQ), and use an application programming interface (API) for status interaction, control command issuance, and test result return. This microservice architecture fully decouples the devices at the software level, avoiding data sharing conflicts and resource configuration conflicts during multi-task concurrency, and also provides a unified interface standard for the integration of heterogeneous instruments. Specifically, each channel can represent a logical entity that can be independently addressed and controlled. For example, a spectrum analyzer can be encapsulated as an analysis channel, a signal source can be encapsulated as an excitation channel, and a physical port of the test sample can be encapsulated as a test channel. The channels interact with each other through an application programming interface (API). The API can be a set of predefined functions or services that allow the flexible scheduling software platform to query the channel status (e.g., idle, busy, fault) and send control commands (e.g., set frequency, start measurement) to it. This enables the software to manage and schedule hardware resources in a unified manner while maintaining logical decoupling between the hardware resources.

[0059] In this embodiment, the flexible scheduling software platform first acquires the test tasks for the sample under test. Test tasks can be obtained based on user input, issued by the production planning system, or retrieved from a local database. A test task may include multiple test items, each corresponding to a specific performance indicator of the sample under test, such as output power, phase consistency, or noise figure. Each test item is associated with the necessary test resources for execution and its dependencies on other test items.

[0060] In this embodiment, the test resources may include general-purpose test instruments (e.g., signal sources, spectrum analyzers, vector network analyzers, noise figure analyzers, etc.), specific ports and paths in the radio frequency routing allocation device, and the excitation signal types and measurement channels required to complete the test.

[0061] In this embodiment, the dependency relationship is used to characterize the order or mutual exclusion conditions of test item execution. For example, some tests require the excitation signal calibration to be completed before measurement, or two test items cannot use the same instrument simultaneously. The dependency relationship can be obtained through predefined test process logic or resource contention analysis.

[0062] In one possible and specific implementation, firstly, the software interface can receive the user-inputted sample identifier (model, serial number) and test parameters (test frequency range, channel selection, test accuracy requirements). Then, based on the sample identifier, the corresponding preset test item set can be retrieved from the test item configuration library. Next, combined with the test parameters, the actual test items to be executed are selected from the set, and each item is associated with the required test resources and dependencies. Dependencies can be static (e.g., test item A must be executed before test item B) or dynamic (e.g., determined in real-time based on resource usage).

[0063] Step S12: Read the pre-configured delay time matrix; wherein the delay time matrix records the delay time information of different test items under different signal transmission paths.

[0064] In this embodiment, the delay time matrix can be a structured dataset used to record the delay time information of different test items under different signal transmission paths. Its function is to quantify the signal transmission delay of test items under different transmission paths, providing an accurate time reference for test scheduling. Specifically, it can take the form of a two-dimensional matrix, a three-dimensional matrix, etc., where each element in the matrix corresponds to the delay time information of a specific test item under a specific signal transmission path.

[0065] In this embodiment, the signal transmission path can be represented as the complete path from the output of the general test instrument, through the switching of the radio frequency routing and distribution device, to the sample under test, and then the transmission of the test response back to the general test instrument.

[0066] In one possible and specific implementation, the flexible scheduling software platform can read a pre-configured delay time matrix from memory. This delay time matrix can be stored in an extended configuration file, and the file format can be a custom format such as .lock. It should be noted that the delay time matrix is ​​designed because when general-purpose instruments are controlled via a standard bus, there are uncertain delays in command transmission, instrument response, and data feedback. Furthermore, the response characteristics of different instrument manufacturers and models vary significantly, making precise scheduling impossible using simple fixed time parameters. Therefore, this embodiment uses pre-measurement and dynamic accumulation to structurally record various delay information in the delay matrix.

[0067] Specifically, the delay time matrix can be a multi-dimensional data structure that records the delay time information of different test items under different signal transmission paths. The delay time information can specifically include typical values, maximum possible time, and minimum possible time. Typical values ​​are used for normal scheduling, while maximum and minimum values ​​are used for boundary case analysis and robustness verification.

[0068] Specifically, the delay time matrix can be constructed into sub-matrices for three parts: the device under test (DUT), the test link, and the general-purpose test instrument. Each sub-matrix can be constructed with the input end of the signal transmission path as the row and the output end as the column, and the matrix elements are the delay times of the corresponding path. For example, in the DUT sub-matrix, the rows represent the input ports of the DUT, and the columns represent the output ports of the DUT, recording the delay of signal transmission between different ports within the DUT. In the test link sub-matrix, the rows represent the input ports of the RF routing and distribution device, and the columns represent its output ports, recording the delay of RF switch switching and cable transmission. The instrument sub-matrix records the time required for the instrument to complete the excitation output or complete the measurement data preparation from receiving the command; the rows and columns can correspond to different functional states of the instrument.

[0069] Step S14: For each test item, determine the corresponding expected delay time based on its associated test resources, signal transmission path, and the delay time information recorded in the delay time matrix.

[0070] In this embodiment, the expected delay time can be expressed as a pre-estimated total time required for the test item to complete signal transmission and obtain the test response from the start of execution. Specifically, it can include the sum of all delays related to the execution of the test item, such as the transmission delay of the signal output from the general test instrument, the switching delay of the RF routing and distribution device, the response delay of the test sample, and the delay of transmitting the test response back to the general test instrument.

[0071] In one possible and specific implementation, for each test item determined in step S10, the flexible scheduling software platform first determines the signal transmission path based on the test resources associated with that item. The signal transmission path may include: excitation instrument output port → RF routing allocation device input port → internal path of the RF routing allocation device → RF routing allocation device output port → test sample input port → internal path of the test sample → test sample output port → RF routing allocation device input port → internal path of the RF routing allocation device → RF routing allocation device output port → measuring instrument input port.

[0072] Then, the flexible scheduling software platform can break down the path into segments corresponding to the device under test, the test link, and the instrument, and look up the delay time information of the corresponding segment from the three sub-matrices read in step S12. For each segment, the matrix can record the typical value, maximum value, and minimum value. The platform can select the typical value as the representative time of that segment.

[0073] Since each segment's submatrix may contain multiple candidate values ​​(for example, an RF routing allocation device may have multiple switching modes, corresponding to different delay times), it is necessary to extract multiple candidate delay times from the submatrix. In this case, the flexible scheduling software platform can use a combination operation to obtain the total delay time of the entire path. The specific steps of the combination operation are as follows: First, flatten the delay time matrix of each segment, that is, convert the multidimensional matrix into a one-dimensional vector; then generate a Cartesian product grid of all possible path combinations, that is, enumerate all combinations of segment candidate values; finally, sum the elements in each grid element-wise to obtain the total delay time of each complete path. From these total delay times, the combination corresponding to the typical value can be selected as the expected delay time for the test project, or the minimum value (for aggressive scheduling) or the maximum value (for conservative scheduling) can be selected according to the scheduling strategy.

[0074] This computational method, based on matrix flattening and Cartesian product, can quickly calculate the delay time of all possible signal links without building a complex network model, providing an accurate time reference for subsequent scheduling, while avoiding the high computational complexity caused by network topology modeling in traditional methods.

[0075] Step S16: Based on the expected delay time of each test item, the dependency relationship between test items, and the occupancy relationship between test resources, generate a parallel test sequence so that test items that do not have resource conflicts and satisfy the dependency relationship are executed in parallel.

[0076] In this embodiment, the generated action can be represented as the flexible scheduling software platform planning the execution order of each test item through a preset scheduling algorithm to form a test sequence that can be executed in parallel. The purpose is to maximize test efficiency while avoiding resource conflicts and satisfying dependencies.

[0077] In this embodiment, the parallel test sequence can be represented as a test execution scheme that groups multiple test items according to preset rules, where the test items in each group can be executed simultaneously (parallel execution), and the groups can be executed in a certain order. Specifically, it can be adjusted according to the number of test items, the scale of test resources, and the complexity of dependencies. Each group is a parallel execution unit, and each parallel execution unit includes a group of test items that do not have resource conflicts and satisfy dependencies.

[0078] In this embodiment, the occupancy relationship between test resources can be represented as the occupancy constraint of different test items on the same test resource. That is, the same test resource can only be occupied by one test item at the same time. Specifically, it can include exclusive occupancy, time-sharing occupancy, etc. For example, a general-purpose test instrument can only execute one test item at a certain time, which is exclusive occupancy; multiple test items can occupy the same test resource in time slices, which is time-sharing occupancy.

[0079] In one possible and specific implementation, after obtaining the expected latency times of all test items, the flexible scheduling software platform enters the scheduling decision phase. The scheduling objective is to execute test items in parallel as much as possible while satisfying all dependencies and avoiding resource conflicts, thereby shortening the overall testing time.

[0080] While large-scale scheduling algorithms in related technologies (such as integer programming and genetic algorithms) can theoretically find optimal solutions, their computational complexity increases exponentially with the number of test items and instruments, making them difficult to implement quickly in real-world production environments. The scheduling algorithm used in this embodiment significantly reduces computational complexity and power consumption while maintaining scheduling effectiveness, enabling scheduling decisions to be completed within milliseconds, thus possessing engineering practicality.

[0081] The flexible scheduling software platform first sorts the test items based on the expected delay time, adopting the Shortest Job First (SJF) strategy, that is, the items with shorter expected delay times are executed first to release resources as soon as possible. The sorting results form the initial test sequence.

[0082] Next, the flexible scheduling software platform can analyze the dependencies between test projects. Dependencies can be directed; for example, if project A must be completed before project B, then A is a prerequisite task for B. The flexible scheduling software platform needs to ensure that no dependency violation occurs in any parallel execution unit (i.e., a subsequent task cannot start simultaneously with a prerequisite task, and must start only after the prerequisite task has completed).

[0083] Meanwhile, the flexible scheduling software platform can consider the resource occupancy relationships of tests. Each test project can exclusively occupy its associated test resources (including instruments, RF routing channels, etc.) during execution. If two projects require the same resource, they cannot be executed simultaneously. The platform can identify conflicting project pairs by analyzing the resource occupancy table.

[0084] To generate parallel test sequences, the flexible scheduling software platform can employ the Heterogeneous Earliest Complete Time (HEFT) algorithm. This algorithm first assigns a priority to each test item, calculated based on factors such as expected latency, path length in dependencies, and resource scarcity. Then, the algorithm allocates the items to available time slots one by one according to priority, while ensuring dependencies and resource constraints are met. During allocation, the platform can consider the real-time status of each channel (obtained via API), such as whether the instrument is idle, whether the RF route is available, and whether the state of the sample under test is stable.

[0085] The final generated parallel test sequence can consist of multiple parallel execution units, each of which can include a set of test items that can be executed simultaneously. There are no resource conflicts between the items, and all dependencies are satisfied (i.e., items within a unit are not mutually exclusive, and items between units are executed in a specific order). Each parallel execution unit corresponds to a time slice; items within a unit are executed concurrently, while items between units are executed sequentially.

[0086] Step S18: Control test resources to execute tests according to the parallel test sequence.

[0087] In one possible and specific implementation, the flexible scheduling software platform can send control commands to each channel via API based on the parallel test sequence generated in step S16, driving the test resources to execute tests. Control commands may include: sending commands to general-purpose test instruments to start measurement, set parameters, and read data; sending commands to the RF routing allocation device to switch paths; and sending control commands to the sample under test (changing operating status, triggering measurement), etc.

[0088] During execution, the platform employs multi-threading technology, allocating independent threads to each test item in the parallel execution unit. Threads can monitor resource status via API to ensure the correctness of concurrent operations. Simultaneously, the platform can obtain real-time device status information and test result return data for each channel via API and compare them with the planned timing of the parallel test sequence. If abnormal status or timing deviations are detected (e.g., an instrument timeout), the platform can dynamically adjust the execution of subsequent tasks, such as reallocating resources, pausing abnormal items, or adjusting start times, to ensure the continuity and stability of the testing process.

[0089] After testing, the platform can collect the actual test time and test result data for each test item, and selectively write the actual test time back to the corresponding position in the delay time matrix in the extended configuration file to dynamically update the matrix. The update rule can be: if the test completes normally without errors, the actual test time is used as the new sample point, and the typical values ​​in the matrix are updated by weighted averaging; if the test reports errors or fails, the original value is retained. Through this continuous self-learning mechanism, the accuracy of the delay time matrix is ​​continuously optimized as the system runs, providing a more accurate time benchmark for subsequent tests.

[0090] Test results can be returned to the platform's data processing module via API. After attaching metadata such as the sample information, project name, and test time, the results are stored in the database according to the standard data structure and a test report can be generated for external output.

[0091] The scheduling method provided in this embodiment solves the problems of data sharing and resource allocation conflicts in parallel testing scenarios by encapsulating general-purpose test instruments, RF routing allocation devices, and test samples into independent and parallel operating channels and enabling state interaction. By pre-configuring a delay time matrix that records the delay time information of different test items under different signal transmission paths, a dynamically adjustable expected delay time benchmark is provided for each test item. Based on this, a parallel test sequence is generated by combining the dependencies and resource occupancy relationships between test items, avoiding resource conflicts and enabling parallel execution of test items that satisfy dependencies. Thus, even when dynamic changes in test parameters cause fluctuations in test time, the test sequence can be dynamically and adaptively adjusted, improving the utilization rate of test resources, shortening the overall test time, and enhancing the stability and scheduling flexibility of the system.

[0092] In some implementations, the step of acquiring the test sample includes:

[0093] Step S102: Receive the test sample identifier and test parameters input by the user.

[0094] In this embodiment, the receiving can be represented as the flexible scheduling software platform collecting information related to the sample to be tested from the user through a preset input interface. The purpose is to provide basic input data for subsequently determining the test items to be executed, identifying dependencies and parameterized constraints.

[0095] In this embodiment, the sample identifier can be a standardized identifier used to uniquely distinguish different samples. Its function is to accurately locate the type, specifications and corresponding test standards of the sample. Specifically, it can include: the model number, production batch number, unique equipment code and specifications of the sample.

[0096] In this embodiment, the parameters to be tested can be specific parameter requirements that the user must follow when testing the sample, inputted according to actual testing needs. These may specifically include: test range parameters (phase shift range, attenuation range), test accuracy parameters, test frequency parameters, and test duration limit parameters, etc.

[0097] In this embodiment, user input can be done manually, by selecting from a drop-down menu, by importing a file, or by automatically filling in some information after reading the sample identifier with a barcode scanner.

[0098] Step S104: Based on the identifier of the sample to be tested, determine multiple test items to be executed from the predefined test item set.

[0099] In this embodiment, the predefined test item set can be represented as a standardized set of test items pre-stored in the control computer's storage module and categorized according to the type of sample under test. Specifically, it can be multiple sub-item sets divided according to the type of sample under test (e.g., multi-channel RF components, single-channel signal modules, microwave devices, etc.). Each sub-item set includes all the conventional test items that need to be performed on that type of sample under test, while reserving flexible space that can be adjusted according to the parameters under test. For example, the predefined test item set corresponding to multi-channel RF components includes conventional items such as phase shift level testing, attenuation level testing, signal amplitude testing, and insertion loss testing.

[0100] In one possible and specific implementation, after obtaining the identifier of the sample under test, the flexible scheduling software platform can query a predefined test item configuration library based on the identifier. The test item configuration library records a set of standard test items corresponding to different types of samples under test. Each test item corresponds to a specific performance indicator test, such as output power test, phase consistency test, and noise figure test.

[0101] For each sample identifier to be tested, a preset test item set can be associated with the configuration library. This set includes all the test items that need to be executed for that sample in regular testing. However, in actual testing, users may only need to execute some of these items, or they may need to filter the items based on the test parameters. Therefore, after retrieving the preset item set, the platform can further filter the test items based on the test parameters received in step S102. For example, if the user specifies that only channels 1-4 are tested, only the test items related to these channels are retained; if the user specifies that only sampling tests are performed, a representative subset is selected from the item set.

[0102] Step S106: Based on the predefined resource mapping relationship, determine the test resources associated with each test project, and identify the dependency relationship and parameterized constraints between test projects that have resource competition based on the parameters to be tested.

[0103] In this embodiment, the predefined resource mapping relationship can be a standardized correspondence between test items and test resources, pre-configured and stored in the control computer (which can be stored in a .lock format extended configuration file). Specifically, it can include a correspondence table between test items and hardware test resources (general test instruments, RF routing and distribution devices, signal transmission cables, etc.) and software test resources (test stimulus generation programs, data acquisition programs, etc.). For example, phase shift level test items correspond to pulse / code generators and vector network analyzers, while attenuation level test items correspond to signal generators and peak power meters.

[0104] In this embodiment, the test items with resource competition can be a combination of two or more test items that require the same test resource. For example, if two test items both require the use of the same spectrum analyzer, then these two test items are test items with resource competition.

[0105] In this embodiment, the parameterized constraints can be constraints on the execution process of the test items generated based on the parameters to be tested. Specifically, they can include constraints on the execution order of test items, constraints on the duration of test resource occupation, and constraints on test accuracy. For example, if the parameters to be tested require high-precision testing, the corresponding test items should prioritize the use of general-purpose testing instruments with higher accuracy, and the duration of test resource occupation should meet the requirements of accuracy testing.

[0106] In one possible and specific implementation, the flexible scheduling software platform can invoke the test items to be executed as determined in step S104, and simultaneously read a predefined resource mapping table. For each test item, the mapping table can be used to match and determine all the test resources required for that test item, including specific general test instrument models, RF routing allocation device interfaces, software test programs, etc., while recording the occupancy rules of each test resource (exclusive occupancy, time-sharing occupancy), and binding and storing the test items with associated test resources. Then, the test parameters received in step S102 are invoked to analyze the resource requirements of all test items to be executed, and test item combinations with resource contention (i.e., multiple test items that need to occupy the same test resource) are identified. For these test items with resource contention, based on the requirements of the test parameters, their dependencies are identified. For example, high-priority test items (high-precision test items) are executed first, forming a sequential dependency relationship to avoid resource conflicts. Simultaneously, parameterized constraints are identified based on the parameters to be tested. For example, the resource usage time of test items can be constrained based on the test duration limit in the parameters to be tested, and the selection of heterogeneous general-purpose test instruments can be constrained based on the test accuracy requirements, ensuring that the execution of test items meets user needs. Finally, the associated test resources of each test item, the dependencies between test items with resource competition, and parameterized constraints can be summarized and organized to form standardized task scheduling basic data, which is stored in the memory of the control computer.

[0107] In some implementations, the step of reading the pre-configured delay time matrix includes:

[0108] Step S122: Read the delay time matrix pre-configured in the extended configuration file; wherein the delay time matrix includes a test device sub-matrix, a test link sub-matrix, and a general test instrument sub-matrix; wherein each sub-matrix is ​​constructed with the input end of the signal transmission path as the row and the output end as the column, and each sub-matrix records at least the typical value of the delay time under the corresponding signal transmission path; wherein the delay time information of the delay time matrix for different test items and different signal transmission paths is the delay time information of the corresponding signal transmission path of each sub-matrix.

[0109] In this embodiment, the extended configuration file can be a standardized file used to store timing, resource, and other configuration data in a flexible manufacturing automated testing system. It is used to adapt to the differentiated timing storage requirements of heterogeneous general-purpose test instruments, thus overcoming the shortcomings of traditional bus control in accurately recording the timing of heterogeneous instruments. Specifically, the extended configuration file can be a .lock format file, an .ini format file, or an .xml format file, etc.

[0110] In this embodiment, the delay time matrix can be a structured dataset used to record various delay times experienced by the signal during transmission in the test system. Its design is based on the decomposition of the test signal transmission path. Specifically, a complete signal transmission path needs to sequentially pass through multiple parts, including a general-purpose test instrument (excitation end), an RF routing distribution device, the device under test (DUT), the RF routing distribution device, and the general-purpose test instrument (measurement end). To accurately describe the delay characteristics of each part, the delay time matrix can be constructed into three independent sub-matrices, corresponding to the DUT, the test link, and the general-purpose test instrument, respectively.

[0111] Specifically, the device-under-test (DUT) submatrix is ​​used to record the delay time of signal transmission within the DUT. The DUT often has multiple input ports and multiple output ports (e.g., an 8-channel multi-channel component has 8 RF ports). The DUT submatrix is ​​constructed with the input ports of the signal transmission path as rows and the output ports as columns. The rows of the matrix correspond to the input ports of the DUT (e.g., ports 1 to 8), and the columns correspond to the output ports of the DUT (e.g., ports 1 to 8). The element value in the i-th row and j-th column of the matrix represents the delay time experienced by the signal from the i-th input port to the j-th output port of the DUT. For DUTs with internally adjustable states (e.g., phase shifters, attenuators), the submatrix can also be extended to a three-dimensional structure, with the third dimension corresponding to different internal state settings to record delay variations under different operating conditions.

[0112] Specifically, the test link submatrix is ​​used to record the delay time of signal transmission in the RF routing distribution device and its connecting cables. RF routing distribution devices often have multiple input ports and multiple output ports, achieving path switching from any input to any output through an internal switch matrix. The test link submatrix is ​​also constructed with inputs as rows and outputs as columns; the rows of the matrix correspond to the input ports of the routing distribution device, and the columns correspond to its output ports. The element value in the i-th row and j-th column of the matrix represents the delay time experienced by the signal from the i-th input port of the routing distribution device to the j-th output port and then transmitted through the corresponding cable. This time includes the switch switching time, the signal transmission time on the PCB board, and the cable transmission time. Since the physical length of different paths and the number of switch stages may vary, the element values ​​at different positions in the submatrix may differ.

[0113] Specifically, the general-purpose test instrument sub-matrix is ​​used to record the delay time generated by general-purpose test instruments when performing test operations. General-purpose test instruments include signal source instruments (generating excitation signals) and measurement instruments (analyzing signals). For signal source instruments, the delay time is mainly the time required for the instrument to output a stable excitation signal from receiving a control command, which may include command parsing time, internal state switching time, and signal setup time, etc. For measurement instruments, the delay time is mainly the time required for the instrument to complete data acquisition and be ready to output measurement results from receiving a trigger signal, which may include signal acquisition time, internal processing time, and data transmission time, etc. The general-purpose test instrument sub-matrix can be constructed with the instrument's input state as rows and output state as columns. For example, rows correspond to the type of command received by the instrument, and columns correspond to the ready state after the instrument completes the corresponding operation; or for measurement instruments, rows correspond to the measurement mode (e.g., spectrum scanning, time-domain measurement), and columns correspond to the data ready state. The matrix elements are the delay time between receiving the command and completing the operation.

[0114] In this embodiment, each submatrix records at least a typical value of the delay time for the corresponding signal transmission path. The typical value can be represented as the delay time measured under normal operating conditions and typical configuration, used for estimating expected time in conventional scheduling calculations. In some embodiments, each submatrix may also record both the maximum and minimum delay times. The maximum value is used for system robustness analysis and worst-case estimation; for example, reserving sufficient time margin during scheduling to avoid timeout conflicts. The minimum value is used for aggressive scheduling scenarios; for example, employing the optimal path combination when pursuing ultimate efficiency.

[0115] In this implementation, it is understood that the latency matrix in the extended configuration file is not static. During system debugging, initial latency values ​​for each path can be obtained through actual measurements and written to the typical value positions in the matrix. During system operation, the actual latency collected after each test can be used to update the values ​​at the corresponding positions in the matrix, continuously improving the matrix accuracy over time. This dynamic update mechanism ensures that the latency matrix accurately reflects the actual latency characteristics of the system, providing a reliable data foundation for subsequent precise scheduling.

[0116] In some implementations, the step of determining the corresponding expected delay time for each test item based on its associated test resources, signal transmission path, and delay time information recorded in the delay time matrix includes:

[0117] Step S142: For each test item, based on its associated test resources and signal transmission path, obtain the delay time information corresponding to the signal transmission path from the test device submatrix, test link submatrix, and general test instrument submatrix respectively.

[0118] In this embodiment, the flexible scheduling software platform can traverse each test item in the test tasks acquired in step S10 and independently perform the delay time information acquisition operation for each item. Specifically, firstly, the signal transmission path used when executing the test item can be determined based on the test resources associated with the test item. The determination of the signal transmission path can be based on the following factors: the type of excitation instrument required by the test item (e.g., signal source, pulse generator), the type of measurement instrument (e.g., spectrum analyzer, vector network analyzer), the designated channel of the sample under test (e.g., left channel, right channel, a certain port), and the current connection status and available ports of the RF routing allocation device.

[0119] In one possible and specific implementation, in the case of output power testing, the signal transmission path can be decomposed into the following segments:

[0120] The first segment involves the excitation instrument (signal source) sending a test signal from its output port;

[0121] The second segment involves the test signal entering a specific input port of the RF routing and distribution device via an RF cable.

[0122] The third segment is where the RF routing and distribution device switches the signal from the input port to the output port connected to the excitation port of the sample under test.

[0123] The fourth segment is where the signal enters the designated input port of the sample under test via a cable;

[0124] The fifth segment is the transmission of the signal from the input port to the output port inside the test sample (through the internal circuitry of the test device).

[0125] The sixth segment is where the signal returns from the output port of the sample under test to a certain input port of the RF routing and distribution device via a cable;

[0126] The seventh segment involves the internal switching of signals to the output port of the measuring instrument by the radio frequency routing and distribution device.

[0127] The eighth segment is where the signal enters the input port of the measuring instrument (power meter) via cable;

[0128] The ninth segment involves the measuring instrument acquiring and processing signals, and then outputting the measurement results.

[0129] In the above path, segments one and nine involve the latency of general-purpose test instruments. Segments two, three, six, seven, and eight involve the latency of the test link (including cables and routing distribution devices). Segments four and five involve the latency of the sample under test. The platform can determine the specific port or status corresponding to each segment based on the specific configuration of the test project.

[0130] In this embodiment, the corresponding delay time information can be found from the three sub-matrices read in step S12 according to the type and port identifier of each segment. Specifically, for segments involving general-purpose test instruments, delay time information can be obtained from the general-purpose test instrument sub-matrice. More specifically, the search can be based on the instrument type, model, current operating mode, and command type. For example, for the time required for a signal source to output a stable signal from receiving a command to set the frequency and start the output, the recorded value can be found in the sub-matrices at the positions corresponding to the set frequency row and the output ready column. For the time required for a power meter to receive a command to start the measurement and for the data to be ready, the recorded value can be found in the sub-matrices at the positions corresponding to the power measurement row and the data ready column. If the sub-matrices record typical, maximum, and minimum values, the platform will at least obtain the typical value, and may also obtain the maximum and minimum values ​​simultaneously for later use.

[0131] Specifically, for segments involving test links, delay time information can be obtained from the test link sub-matrix. This can be based on the input and output port numbers of the routing allocation device. For example, for a path from input port 2 to output port 5, the corresponding delay time can be found in the 2nd row and 5th column of the sub-matrix. This time includes switch switching delay, PCB board transmission delay, and cable transmission delay. If the path has multiple switching methods (e.g., through different internal switch cascade paths), the sub-matrix may record multiple candidate values, and the platform needs to obtain all possible candidate values.

[0132] Specifically, for segments involving the sample under test, delay time information can be obtained from the submatrix of the device under test. This can be based on the input and output port numbers of the sample under test. For example, the delay from input port 1 to output port 1 (the direct path) can be found in the first row and first column of the submatrix. If the sample under test has adjustable states (such as phase shifters or attenuators), and the current test item specifies a particular state setting, then the delay time also needs to be obtained from the corresponding depth layer of the 3D matrix based on the state information.

[0133] It should be noted that, since the complete signal transmission path of a test project may correspond to multiple segments, and each segment may correspond to multiple candidate values ​​in the submatrix (for example, the routing path is not unique), the delay time information obtained in this step is often not a single value, but a set or vector of multiple values. This information will be temporarily stored as input for the next step of combination operation.

[0134] Step S144: Perform combined calculations on the delay time information of each submatrix to obtain the expected delay time of the test item under the corresponding signal transmission path.

[0135] In some implementations, the step of combining the delay time information of each acquired submatrix to obtain the expected delay time of the test item under the corresponding signal transmission path includes:

[0136] Step S1442: For the delay time information of each submatrix obtained, perform flattening, Cartesian product grid generation, and element-by-element addition processes in sequence to obtain the full-link delay time of the signal transmission path, and use the full-link delay time as the expected delay time of the test item.

[0137] In this embodiment, the flattening process is used to convert the multi-dimensional delay time data sets obtained from different sub-matrices and stored in categories in step S142 into single-dimensional ordered data. This process eliminates differences in data classification levels and dimensions, and unifies the data format. Specifically, it may include sorting the delay data of general test instruments, test link delay data, and device-under-test delay data separately, and then merging them into a one-dimensional continuous data sequence without changing the magnitude and attributes of individual delay time values.

[0138] In this embodiment, the Cartesian product grid processing can be represented as a processing operation that performs combined enumeration on the flattened one-dimensional data sequence to generate a complete set of combinations in which all segment delay times match each other. This is used to cover all feasible delay combination scenarios in the complete signal transmission path. Specifically, it can include enumerating all pairwise or more corresponding combinations of general test instrument delay, test link delay, and device under test delay. Each combination corresponds to a matching scheme for a segment delay in the complete signal transmission path.

[0139] In this embodiment, the element-wise addition process involves summing all values ​​within each complete delay combination in the Cartesian product grid to obtain the total delay of the complete signal transmission path corresponding to that combination. Specifically, this can be done by sequentially summing the instrument delay, link delay, and device-under-test delay within a single combination, or by independently summing multiple combinations.

[0140] In some implementations, the step of generating a parallel test sequence based on the expected latency of each test item, the dependencies between test items, and the resource occupancy relationships between test items, so that test items that do not conflict with resources and satisfy dependencies are executed in parallel, includes:

[0141] Step S162: Using the expected delay time of each test item as the job duration, the test items are initially sorted using the shortest job priority strategy to generate an initial test sequence.

[0142] In one possible and specific implementation, the flexible scheduling software platform can first use the expected delay time of each test item calculated in step S14 as the job duration of that item. The job duration is the time required for the item to be executed from start to finish, and it is the basic unit for measuring task size in the scheduling algorithm.

[0143] All test items can be sorted according to their expected latency, from shortest to longest, with shorter expected latency items placed first and longer expected latency items placed later. This is understandable, as prioritizing shorter-duration items releases their allocated test resources more quickly, allowing subsequent items to acquire resources and begin execution sooner, thus shortening the overall test completion time and improving resource turnover efficiency.

[0144] After prioritizing the shortest jobs, an initial test sequence can be obtained. This sequence can be a one-dimensional list, where test items are arranged in ascending order of job duration. The initial test sequence only considers the expected latency of the items and does not yet include dependencies and resource consumption relationships between items. Therefore, this sequence serves only as a preliminary basis for subsequent optimization scheduling, rather than a final executable test plan.

[0145] Step S164: Based on the dependencies between test items and the occupancy of test resources, and combined with the channel status information obtained through the application programming interface, assign a priority value to each test item; wherein, the channel status information includes the real-time availability status of general test instruments, RF routing allocation devices, and the sample under test.

[0146] In a possible and specific implementation plan, the dependencies between test items can be analyzed first. Based on the test item dependency constraints determined in step S10, projects on the critical path can be identified, that is, projects whose execution delays will directly affect the overall test cycle. These projects can be assigned higher priority. For projects with prerequisite dependencies, if the prerequisite projects have been sorted and there is no risk of execution delay, the priority is appropriately increased. If the prerequisite projects have not been sorted, the priority is not increased for the time being. There is no need to use complex graphical analysis; the basic priority is assigned based solely on the actual constraints of the dependency relationships to reduce computational power consumption.

[0147] Secondly, the occupancy relationships of test resources can be analyzed. Based on the test resource mapping relationships determined in step S10, test items occupying scarce heterogeneous general-purpose test instruments (high-precision vector network analyzers) and core RF routing ports can be identified. These items can be given higher priority to ensure efficient utilization of scarce resources and avoid resource idleness. For items without resource contention and only occupying ordinary test resources, priority is allocated according to basic rules, eliminating the need to construct complex resource conflict graphs and simplifying the analysis process.

[0148] The status information of each microservice channel can be obtained in real time through the application programming interface (API), so that the priority allocation is aligned with the actual operation of the system and avoids the disconnect between the planning based on ideal state and reality. Specifically, it can include: the real-time availability status of general test instruments (whether the instrument is idle, whether it is executing a task, whether it has failed / is offline, whether it is in self-calibration state, etc.), the real-time availability status of RF routing and allocation devices (whether the specified input and output ports are occupied, whether the internal switch matrix is ​​busy, whether the path switching has been completed, etc.), and the real-time availability status of the sample under test (whether the sample is correctly connected, whether it is in a stable working state, whether it has completed preheating / cooling, whether it is ready to be tested, etc.).

[0149] In a possible and specific implementation, a low-complexity weighted summation method can be used to assign a priority value to each test item (preferably using integers from 0 to 10, with larger values ​​indicating higher priority; the weights can be flexibly adjusted according to the application scenario). The urgency of dependencies, resource scarcity, and channel real-time readiness status are each assigned a corresponding weight, and the summation yields the overall priority.

[0150] Step S166: Using the initial test sequence, the priority value of each test item, and the dependency relationship between test items as input, the heterogeneous earliest completion time algorithm is used for iterative optimization to generate a parallel test sequence; wherein, each parallel execution unit in the parallel test sequence includes a set of test items that do not have resource conflicts and satisfy the dependency relationship, and the parallel execution units are sorted according to the expected delay time and priority value of the test items.

[0151] In this embodiment, the initial test sequence generated in step S162, the priority values ​​assigned in step S164, and the dependencies between test items can be used as inputs. The Heterogeneous Earliest Complete Time (HEFT) algorithm, adapted to the characteristics of heterogeneous general-purpose test instruments, is employed to generate parallel test sequences through finite iteration optimization. It can be understood that the heterogeneity refers to the diversity of test resources, that is, different models of heterogeneous general-purpose test instruments have different response characteristics and delay parameters, different ports of the RF routing allocation device have different switching delays, and different channels of the test sample have different internal transmission delays. The HEFT algorithm can effectively adapt to this heterogeneous environment and has low computational complexity, requiring no high computing power.

[0152] In one possible and specific implementation scheme, it may specifically include:

[0153] (1) The platform sorts the test items in descending order according to their priority values ​​and generates a list of items to be scheduled. Items with higher priority values ​​are listed first and are given priority for scheduling.

[0154] (2) Initialize an empty scheduling table, which includes multiple time slots, each time slot corresponding to a time slice in which multiple test items can be executed in parallel.

[0155] (3) Take the highest priority test item from the list to be scheduled and try to insert it into a time slot in the scheduling table. The following conditions must be met when inserting: the predecessor project that the project depends on has been completed (i.e., it has been scheduled to the previous time slot and its completion time is earlier than the start time of the current time slot); all the test resources required by the project are available in the current time slot, i.e. no other projects scheduled to the same time slot are occupying these resources; after insertion, the completion time of the project (i.e. the start time of the current time slot plus the expected delay time of the project) will not cause subsequent projects to fail to satisfy its dependency.

[0156] (4) If multiple time slots can satisfy the above conditions, the algorithm selects the time slot that makes the project complete earliest for insertion. The calculation of completion time can take into account the heterogeneity of resources, that is, the same project may be executed in different time slots, and the actual delay time may be slightly different due to different resource states. However, in this embodiment, the expected delay time has been accurately calculated by the delay time matrix, so it can be considered that the execution time in different time slots is the same.

[0157] (5) If there is no available time slot that meets the conditions, the algorithm creates a new time slot, inserts the item into it, and sets the start time of the new time slot to the latest completion time of the currently scheduled item.

[0158] (6) Update the resource usage table and mark that the resources occupied by this project have been occupied in the current time slot.

[0159] (7) Repeat (3) to (6) until all test items have been scheduled.

[0160] After the above iterative optimization, a scheduling table with multiple time slots can be generated. Each time slot corresponds to a parallel execution unit, which includes a set of test items that can be executed simultaneously. There are no resource conflicts between the items (i.e., the test resources they use do not overlap), and they satisfy dependency relationships (i.e., items within a unit are not mutually exclusive, and items between units satisfy a certain order).

[0161] In one possible and specific implementation, in the final parallel test sequence, the parallel execution units are ordered according to the following rules: priority is given to ordering by the average expected latency of the test items within the unit, with units of shorter duration being executed first to facilitate the rapid release of test resources; if the units start at the same time, the unit containing high-priority items is executed first to ensure the rapid progress of critical items; and dependency constraints are strictly followed, with the unit containing a subsequent item being placed after the unit containing its preceding item to avoid dependency conflicts.

[0162] In some implementations, the step of controlling test resources to execute tests according to the parallel test sequence includes:

[0163] Step S182: According to the timing of the parallel test sequence, send control commands to the corresponding channels through the application programming interface to drive the general test instrument to generate test stimuli, control the RF routing and distribution device to switch signal paths, and obtain the test response of the sample under test.

[0164] In this embodiment, the flexible scheduling software platform can begin actually executing test tasks based on the parallel test sequence generated in step S16. It can sequentially start each parallel execution unit according to the timing relationships defined in the sequence, and execute multiple test items in parallel within each unit.

[0165] Specifically, the parallel test sequence is first parsed to obtain the start time of the first parallel execution unit and the list of test items included in that unit. For each test item within the unit, the corresponding channel can be determined, which may include the excitation instrument channel, RF routing channel, test sample channel, and measurement instrument channel. Each channel has been encapsulated as an independently running microservice at the software level, and its control interface and status query interface are exposed through an application programming interface.

[0166] In one possible and specific implementation plan, corresponding control instructions can be constructed according to the specific needs of each test item. The control instructions may specifically include:

[0167] For excitation instruments (signal sources, pulse generators) in general-purpose test equipment, control commands are used to set parameters such as the frequency, power, waveform, and modulation method of the output signal, and to trigger signal output. The command format follows the SCPI command set or dedicated API functions provided by the instrument manufacturer. The platform sends the commands to the corresponding instrument channel via the API, and the instrument begins to generate the test excitation signal after receiving the command.

[0168] For RF routing and allocation devices, control commands are used to switch signal paths, connecting the output port of the excitation instrument to the designated input port of the sample under test (SUT), and connecting the designated output port of the SUT to the input port of the measuring instrument. The command content can include the source port number and the destination port number. The platform sends the switching commands to the control channel of the routing and allocation device via API, and the internal switching matrix of the device completes the physical path connection according to the commands.

[0169] For the sample under test, if the sample itself has controllable functions (e.g., adjustable attenuator, phase shifter, working mode switching), control commands can be used to set the working state of the sample to a mode suitable for the current test item.

[0170] For measurement instruments in general-purpose test equipment (e.g., spectrum analyzers, vector network analyzers, power meters), control commands are used to set measurement parameters (such as center frequency, scanning bandwidth, and detection mode) and trigger data acquisition. After completing the measurement, the instrument returns the measurement data to the platform via API.

[0171] Step S184: During the test, the device status information of each channel is obtained in real time through the application programming interface.

[0172] In this embodiment, the device status information may specifically include the status of general-purpose test instruments, the status of the RF routing allocation device, and the status of the sample under test. Specifically, the status of the general-purpose test instruments may include whether the instrument is online, busy, in an error state, undergoing self-calibration, whether the current temperature is normal, and whether the memory buffer is full. For ongoing measurement tasks, the status information may also include measurement progress and estimated remaining time. The status of the RF routing allocation device may include the connection status of the specified port, whether the switch switching is complete, the current path occupancy status, and whether there is signal overload or abnormal reflection. The status of the sample under test may include whether the sample is correctly connected, whether the power supply is normal, whether the internal temperature is stable, whether it is in a preset working mode, and whether there is a communication failure.

[0173] Step S186: Based on the acquired device status information and the planning of the parallel test sequence, the execution of the test task is dynamically adjusted when an abnormal status or timing deviation is detected.

[0174] In this embodiment, during test execution, the device status information obtained in step S184 can be compared with the parallel test sequence plan in real time. Once a status anomaly or timing deviation is detected, a dynamic adjustment mechanism is triggered. The goal of the adjustment is to restore the planned execution or replan subsequent tasks as much as possible without interrupting the overall test process, so as to reduce the impact of anomalies on test efficiency. Corresponding and preset adjustment strategies can be adopted according to the type of deviation.

[0175] Specifically, if the instrument fails to respond or returns to a busy state within a specified time, the platform can wait briefly and then retry. If multiple failures occur, the current project will be temporarily suspended, and other projects in the same unit that do not depend on the faulty instrument will be executed first. If the instrument cannot recover for an extended period, the scheduling algorithm will be invoked to reschedule incomplete projects, skipping the faulty instrument or switching to a backup instrument.

[0176] Specifically, if the path switching command returns an error or an abnormal status, the command can be resent. If this still fails, an alternative path is retrieved from the delay time matrix and a switching attempt is made. After multiple failures, the path is marked as faulty, and subsequent scheduling is notified to avoid using it.

[0177] Specifically, when the sample temperature exceeds the limit or communication is interrupted, the platform suspends the current test and waits for the sample to recover; if the anomaly is caused by continuous testing, the order of subsequent tests is adjusted, and projects with lower requirements for sample status are executed first.

[0178] Specifically, if the actual execution time of a project significantly exceeds expectations, causing delays in subsequent tasks, the start time of subsequent units can be dynamically postponed to ensure dependencies are maintained. Alternatively, the remaining projects can be rescheduled based on the current progress. If preceding projects are completed ahead of schedule, subsequent projects can be started earlier to reduce waiting time.

[0179] Specifically, when an anomaly causes a delay in resource release or unexpected resource occupation, the startup of conflicting projects can be postponed while waiting for resources to be released. If an alternative instrument with the same functionality exists, it can be switched to and the path reconfigured.

[0180] In some embodiments, the method further includes:

[0181] Step S110: After completing the test according to the parallel test sequence, obtain the actual test time of each test item under the corresponding signal transmission path.

[0182] In one possible and specific implementation, the flexible scheduling software platform can extract the actual test time for each test item from the execution log or result database after the test execution is completed. The actual test time can be the real duration from the start of the item's execution (sending the first control command) to its completion (acquiring the final test data). The platform also records the specific signal transmission path used during the execution of the item, including the excitation instrument, measuring instrument, RF routing path, and the input / output ports of the sample under test, so that the actual time can accurately correspond to the specific position in the delay time matrix.

[0183] Step S112: Write the actual test time back into the delay time information position of the corresponding signal transmission path in the delay time matrix in the extended configuration file, so as to dynamically update the delay time matrix.

[0184] In one possible and specific implementation, the flexible scheduling software platform can locate the corresponding element of the delay time matrix in the extended configuration file based on the actual signal transmission path of each test item. This includes the delay time records of relevant paths in the test device submatrix, test link submatrix, and general test instrument submatrix. The actual test time is then segmented or correlated as a whole, and the delay time information at the corresponding location is updated. The update strategy can employ methods such as moving average, direct replacement, or extreme value updates to gradually approximate the typical, maximum, and minimum values ​​in the matrix to the actual system characteristics. The updated matrix is ​​persistently stored in the extended configuration file for use by subsequent test tasks, thereby achieving self-learning and continuous optimization of the system's delay characteristics.

[0185] This embodiment provides an automated testing system for flexible manufacturing, including:

[0186] A control computer is configured with a flexible scheduling software platform; wherein the flexible scheduling software platform is configured to execute the scheduling method provided in the above embodiments.

[0187] One or more general-purpose testing instruments are communicatively connected to the control computer.

[0188] The radio frequency routing and distribution device is communicatively connected to the control computer and connected to the general-purpose test instrument and the sample under test, respectively, and is used to switch the test signal path under the control of the control computer.

[0189] The flexible scheduling software platform encapsulates the general-purpose test instrument, radio frequency routing allocation device, and test sample into independent and parallel channels, and realizes state interaction through application programming interface.

[0190] In this embodiment, the control computer serves as the system's control core and is equipped with a flexible scheduling software platform. The control computer can connect to other devices in the system via standard communication interfaces such as GPIB, LAN, USB, and serial ports, and is responsible for executing each step of the scheduling method.

[0191] In this embodiment, the general-purpose testing instrument may specifically include a signal source, pulse generator, spectrum analyzer, vector network analyzer, power meter, and noise figure analyzer, etc. The general-purpose testing instrument is used to generate excitation signals and measure the response signals of the sample under test during the testing process.

[0192] In this embodiment, the RF routing and distribution device is communicatively connected to the control computer and connected to both a general-purpose test instrument and the sample under test via RF cables. The RF routing and distribution device integrates a switch matrix, enabling it to connect the output port of any general-purpose test instrument to any input port of the sample under test, and to connect any output port of the sample under test to the input port of any measuring instrument, under the command of the control computer, thereby achieving flexible switching of the test signal path.

[0193] like Figures 2-4 As shown, in one specific implementation, a scheduling method for testing resources such as general-purpose instruments in a flexible manufacturing system is provided.

[0194] In existing automated test systems, as the number of test sample channels and the number of test resources required to be connected increase, the overall test time and the complexity of the test system also increase dramatically. Therefore, in the automated testing of multi-channel DUTs, flexible automated test systems are usually introduced to improve the utilization rate of test instrument resources and shorten test execution time. However, existing systems often have the following problems:

[0195] 1. Existing automated testing systems for flexible manufacturing generally employ modular instruments during their construction, lacking the design and application of parallel testing systems built using general-purpose instruments. Currently, general-purpose instruments still have a wide range of applications in the debugging and testing of multi-channel components, while automated testing systems using modular instruments cannot be directly applied to testing systems built with general-purpose instruments, resulting in a narrow application range in actual production and debugging processes.

[0196] 2. The original automatic test scheduling plan was often static or quasi-static. As the automatic test sequence was generated, the test order of the test items in the test sequence would be fixed. If the test items did not need to be changed, but only the test parameters were added or removed, the change in the test time of the test items that caused the parameter change would often require the system to be re-planned. Otherwise, deadlock or conflict would occur, which would seriously affect the system stability and overall test efficiency.

[0197] Taking an 8-channel multi-channel component as an example, the complete test parameters for a single channel include 32 phase shift levels and 64 attenuation levels. Different numbers of parameters need to be tested at different stages of the test, leading to significant variations in the test time for phase shift testing and programmable attenuation. The time difference between full-parameter testing and non-full-parameter testing can reach tens of minutes. Without replanning the automatic test sequence or test scheduling, this can result in idle test resources within the system or conflicts in parallel system tests.

[0198] 3. The nodes and transmission links in the existing automatic test scheduling network model lack the ability to represent information content, such as the impact of project test time on the state of the sample under test, test parameters, and the impact of changes in transmission links on test time.

[0199] The temperature and transmit / receive performance of multi-channel components are related to the test duration and the order of test items. Testing not only requires completing each item but also maintaining the state of the sample under test in a relatively stable state throughout the test. Different test sequences and parameters will result in different states of the multi-channel components. To ensure the stability of the sample under test, the automated test sequence needs to be redesigned. Furthermore, directly using equivalent genetic algorithms or scheduling plans often fails to meet the test requirements.

[0200] 4. The existing automatic test sequence establishment process and inference algorithm process of flexible manufacturing are relatively complex. Not only does it require the construction of a complex parallel network model, but it also requires continuous updates to the network model as the parameters of the test item change or increase. This leads to the continuous increase of the state space of the parallel network model, resulting in high resource costs and computing power costs for the flexible manufacturing system, and thus the system has the disadvantage of low energy efficiency.

[0201] The main technical problems to be solved by this implementation plan are as follows:

[0202] 1. The scheduling method of the flexible manufacturing automatic testing system provided in this implementation plan can meet the planning of flexible automatic testing systems for general instruments. It can realize the simultaneous testing of multiple test items using different test resources and the sequential execution of test items using the same test resources. It can significantly improve testing efficiency without increasing the energy consumption of the automatic testing system or reducing the testing accuracy of the automatic testing system.

[0203] 2. The scheduling method provided in this implementation plan encapsulates general-purpose instruments into independent and parallel "channels" in flexible scheduling software. Different "channels" have software interfaces for synchronization information and instrument status information, which solves the data sharing conflict and resource allocation conflict problem of multiple general-purpose instruments in the scheduling scenario of flexible manufacturing, and realizes the application of general-purpose instruments in the automatic testing system of flexible manufacturing.

[0204] 3. The scheduling method provided in this implementation plan expands the delay time matrix in the configuration information file, increasing the typical test time of the test items, the range of delay requirements for test resources and samples under test, and the theoretical and typical values ​​of link transmission delay time. This provides an accurate data foundation for the global time management of the flexible scheduling software platform. Furthermore, when the test items remain unchanged but only the test parameters are changed, the test time under those parameters can be obtained by reading the delay time matrix, simplifying the planning strategy of the test sequence. At the same time, it greatly reduces the computational complexity of the entire system, which facilitates the improvement of the generation efficiency of the test sequence and the stability of the system, and reduces the overall energy consumption ratio of the entire system.

[0205] 4. The scheduling method provided in this implementation plan adds a test sample state management function, incorporates the test sample state into the test sequence planning, makes the system test results more consistent with the actual test results, reduces system conflicts and deadlocks, and improves the stability and accuracy of the system.

[0206] The scheduling method for general-purpose instruments in the flexible manufacturing automated testing system of this implementation plan (hereinafter referred to as the scheduling method) includes: a flexible scheduling software platform, testing resources (test instruments, test cables and accessories), an RF routing allocation device, and communication equipment between samples under test (GPIB cables, GPIB-USB adapters, and network cables). The specific functions implemented by the scheduling method are as follows:

[0207] 1. In the flexible manufacturing system, general-purpose instruments, equipment, and test samples are encapsulated into different "channels" within the flexible scheduling software. These channels operate independently and in parallel, with interfaces only for synchronization information and exchanging instrument and equipment status information. This fundamentally eliminates data sharing and resource allocation conflicts in concurrent general-purpose instrument scenarios. The flexible scheduling software encapsulates signal flow (RF routing) and input / output, and individual microservices into "channels." Channels exchange time synchronization information and status information of general-purpose instruments, equipment, and test samples via a distributed message queue (RabbitMQ). A standardized status interaction interface is provided through a REST API, enabling full decoupling between test resources, RF routing allocation devices, and test samples.

[0208] 2. The transmission mechanisms in the data transmission process between the instrument and the processor are analyzed, and the typical transmission delay error is calculated based on the time accuracy of the transmission mechanism protocol. Combined with the length of each transmission line in the system, the precise transmission delay between systems is calculated. Specifically, the switching delay time of the RF routing allocation device can be calculated as the PCB board processing time plus the switching time of each level of switch; the more switch levels, the longer the switching delay time. Typical delay times for test resources are divided into general-purpose instruments for signal transmission and general-purpose instruments for signal analysis. For transmission equipment, only the instrument function switching time needs to be calculated; for receiving equipment, the instrument configuration information needs to be read to calculate the time required for the instrument function to be implemented. During test project debugging, the typical test time, the required range of delay time for test resources and samples under test, the theoretical values ​​(i.e., maximum and minimum values) and typical values ​​of the link transmission delay time are written into the delay time matrix in the system software's additional extended configuration information file (.lock file) for use by the global subtask scheduling module. The delay matrix is ​​divided into three parts: the device under test, the test link, and the test instrument. Each part has three delay time matrices: maximum delay, minimum delay, and typical delay. The delay matrix is ​​a two-dimensional matrix. The columns represent the signal input (in), i.e., the output end of general-purpose signal transmitting instruments, and the columns represent the signal output (out), i.e., the input end of general-purpose signal analysis instruments. The matrix values ​​are the delay time values ​​between in and out. The flexible scheduling software platform writes the typical delay time values ​​obtained during project debugging, along with the calculated maximum and minimum delay time values, into the corresponding delay matrices as the initial values. After testing by the automatic testing system, if the test does not report errors, the delay time for each test is written back to the corresponding position in the delay time matrix of the .lock file. If the test reports errors or fails, the original delay time values ​​in the .lock file are retained. Taking the delay matrix of an 8-port product requiring 6 test resources as an example, its format is as follows:

[0209]

[0210] 3. The specific usage of the delay matrix is ​​as follows: Based on the test resources, RF routing switching devices, and the sample under test traversed by the signal transmission link, the delay matrix of each part is flattened, a Cartesian product grid is generated, and then element-wise summed to form all possible signal links. The resulting matrix from the operation of each pair of matrices has a dimension of (the total number of elements in matrix A multiplied by the total number of elements in matrix B), and the value at each position corresponds to the sum of a pair of elements in matrices A and B. This forms all the delay time data required by the parallel test scheduling software.

[0211] 4. By attaching extended configuration information files (.lock files) to the general instruments, equipment, and test samples in the flexible scheduling software, the delay time matrix of each part in the configuration information file is automatically read during the execution of the parallel sequence generation module algorithm. The parallel sequence generation module generates parallel sequences based on this matrix, realizing dynamic planning of test sequences by the test software. The algorithm of the parallel sequence generation module first uses the shortest job first (SJF) method to integrate the required resources according to the signal link. Since the platform scheduling algorithm needs to handle a large number of general instruments, i.e., heterogeneous resources, and there are strong dependencies between heterogeneous resources (i.e., the RF signal needs to be emitted from the signal generation device, pass through the test device, and then obtain the test results through the signal analysis device; there are strong dependencies between different general instruments; incorrect operation order of general instruments or incorrect signal path will directly affect the test results); then the platform algorithm uses task priority calculation, assigning a priority value to each task according to the degree of impact of different tasks on the overall application completion time; finally, the heterogeneous earliest finish time (HEFT) algorithm is used to sort the job processes, forming a parallel test strategy for each process according to the order of highest test efficiency. The algorithm has a time complexity of O(v²p), where v is the number of tasks and p is the number of general-purpose instruments. It has low complexity and good scalability. In contrast, complex algorithms such as integer programming algorithms may experience exponential growth in complexity as the number of general-purpose instruments increases, making them unable to handle parallel planning tasks with a large number of general-purpose instruments.

[0212] The hardware environment targeted by this parallel test scheduling scenario includes various heterogeneous execution units such as general test instruments and radio frequency routing switching devices. This environment can essentially be abstracted as a multi-processor heterogeneous computing architecture (i.e., heterogeneous processors) with differentiated computing capabilities, task processing latency and interface interaction characteristics. Furthermore, there may be dependencies between multiple tasks, which makes it difficult to directly apply the original parallel test task scheduling strategy to the generation of parallel test sequences in this scenario.

[0213] Since the scheduling involves general-purpose instruments and RF routing switching equipment, i.e., a heterogeneous computing environment with multiple processors, the core of the algorithm is to calculate the typical delay times and delay matrices of each stage obtained through debugging or prior system operation before generating parallel test tasks. This is achieved using a low-complexity algorithm to generate the parallel test strategy with the shortest overall time. From a software algorithm design perspective, this solution fundamentally achieves dual optimization in parallel sequence generation: on the one hand, by modeling with pre-test data and selecting a low-complexity algorithm, the complexity of generating parallel test sequences is significantly reduced, shortening the algorithm's computation time and avoiding problems such as excessive computational resource consumption and long strategy generation delays caused by complex scheduling logic; on the other hand, compared to the traditional scheduling mode that requires building complex network topology models and simulating multi-node interactions to generate parallel test sequences, this solution does not require additional computational resources for network morphology modeling and verification, significantly reducing the time and computational costs in the parallel test sequence generation process, improving the engineering practicality and execution efficiency of the scheduling strategy, and making it more suitable for the parallel testing needs of medium-sized clusters and heterogeneous hardware environments.

[0214] 5. Add test status control function, take the status of the sample to be tested as the system parameter, use the system parameter as the basis for generating test sequences in the test sequence generation algorithm, plan the optimal strategy for test sequences, and enhance the accuracy of the flexible manufacturing automatic test system.

[0215] 6. To address the channel count and test status requirements of multi-channel components, a dedicated RF link routing and allocation device is designed to enable different types of multi-channel component channels to simultaneously connect to different test resources. Taking an 8-port multi-channel component as an example, the multi-channel component port is divided into four channels on the left and four on the right. When designing the dedicated RF link routing, two SP4T switches are used to connect the multi-channel component ports, with the left and right channels each connected to one switch. At the test resource ports, two SP2T switches are used to ensure that the RF links between the left and right channels do not interfere with each other, and that each channel on both the left and right sides can connect to the test resource.

[0216] The instrument resources and test items required for testing an 8-port multichannel component are shown in the table below:

[0217] Table 1 Test Tasks and Resource Usage

[0218]

[0219] The peak power analyzer is r1, the vector network analyzer is r2, the spectrum analyzer is r3, the noise figure analyzer is r4, the signal source is r5, and the pulse / code generator is r6. The signal source and the pulse / code generator provide the excitation signal to the sample under test.

[0220] Taking the flexible manufacturing automated testing system for an 8-port multi-channel component as an example, the testing methods and steps of this implementation scheme are as follows:

[0221] 1. Connect the left and right channels of the sample under test to the corresponding input ports of the RF link routing distribution device, and connect the power meter, vector network analyzer, spectrum analyzer, noise figure analyzer and noise source to the corresponding output ports of the RF link routing distribution device. Connect the signal source and pulse / code generator to the RF link routing distribution device. Transmit the excitation signal to the excitation port of the sample under test through the RF link routing distribution device. Connect all test resources and devices to the system.

[0222] 2. Input the name of the sample to be tested, the number of samples to be tested, test parameters, test resource information and other information into the flexible scheduling software platform; the information input module reads the time matrix information in the test item corresponding to the name of the sample to be tested and the extended configuration information file (.lock file) corresponding to the test item, and transmits the information to the subtask generation module;

[0223] 3. The automatic testing system plans the test sequence based on the test resources and the number of samples to be tested, forming a test strategy. This strategy includes the state requirements of the test items and the minimum delay time between adjacent logically related test items in the test sequence. Test subtasks are formed in the subtask generation software module of the software platform. Automatic test subtasks can only be processed through "pipelines", which fundamentally avoids conflicts and deadlocks between subtasks.

[0224] 4. Based on the typical test time of each test item in the delay time matrix of the extended configuration information file (.lock file) in the software platform, as well as the typical test state and the test state required by the sample to be tested, and combined with the number and logical relationship of the parallel test subtasks, a weight label is formed on each test item. The subtask scheduling software module of the software platform uses the weight of the test item as a parameter to plan the optimal strategy for the test sequence.

[0225] 5. In the automatic testing module, test tasks are executed according to the optimal test sequence planned by the automatic testing global subtask scheduling module, and test data is generated;

[0226] 6. The test data from the automatic testing module is transmitted to the test data processing module. The data processing module adds information such as test item name and test time to the test data, forms a database file according to the standard data structure, and provides the data information to the external data interface. It can be displayed on the software platform interface or read from the interface in real time to ensure the transparency and reliability of the test results.

[0227] In this implementation plan, the system mainly consists of a control computer and flexible scheduling software platform, radio frequency link routing and allocation device, general instrument excitation source, and general test instrument resources (including test instruments, test cables and accessories).

[0228] Among them, such as Figure 2 and Figure 3 As shown, the structural principle of the flexible scheduling software and the function of each module are explained below:

[0229] 1. Test Resource and Test Project Information Input Module: The software requires users to input relevant information about the samples to be tested, including the type and quantity of the samples, and to select the test projects and test parameters.

[0230] 2. Subtask Generation Module: This module contains the test resources required for each task and exposes the status of these resources to the subtask scheduling software module via an interface. Based on a delay time matrix composed of time information such as the test time and the time interval between the minimum and maximum link transmission delay times in the extended configuration information file (.lock file) of existing automatic test projects during debugging, the subtask generation module adds time "tags" to the test projects in the platform software, thereby generating the platform software's test subtasks.

[0231] 3. Subtask Scheduling Module: The subtask scheduling module starts timing from zero using a global clock from the initial state enable moment. The time information of each module is interconnected, realizing global time management for all modules of the software platform. The subtask scheduling module reads the time information from the extended configuration information file and calculates the optimal test sequence based on the test resource status information and the test sample status weight information through the algorithm of the parallel sequence generation module.

[0232] 4. Automatic Testing Module: Each test item starts with an independent thread. The only way to exchange information between threads is through the resource status interface. If there is no resource usage conflict between threads, there will be no other data, variable or other information exchange. After the automatic testing module completes the test, it writes the test time information back into the delay time matrix of the extended configuration information file (.lock file) and gradually improves the information of the delay time matrix during the test.

[0233] 5. Test Data Processing Module: Based on the test results read from the test resources, this module adds information such as the sample to be tested, project name, and test time, and forms a database file according to a unified data structure.

[0234] 6. Test Report Generation Module: Reads test results and sample information from the database file and generates the final test report according to the template format.

[0235] Compared with the existing technology, this implementation scheme has the following advantages:

[0236] 1. This solution enables the planning of a flexible manufacturing automatic testing system for general-purpose instruments. By encapsulating general-purpose instruments into independent and parallel "channels" in flexible scheduling software, it solves the data sharing and resource allocation conflicts of multiple general-purpose instruments in testing scenarios, and realizes the application of general-purpose instruments in automatic testing systems.

[0237] 2. This solution can effectively improve overall testing efficiency. Taking an 8-channel multi-channel component (single-channel test parameters include 32 phase shift levels and 64 attenuation levels) as an example, without increasing the energy consumption of the automatic testing system or reducing the testing accuracy of the automatic testing system, the average utilization rate of the test equipment in the parallel automatic testing system is increased by about 23%, and the testing time is shortened by about 33%.

[0238] 3. This solution can effectively simplify the planning strategy of test sequences by automatically writing and reading the delay time matrix in the extended configuration information file, greatly reduce the computational complexity of the entire system, improve the generation efficiency of automatic test sequences and system stability, and reduce the overall energy consumption ratio of the system.

[0239] 4. This solution improves system stability and accuracy by adding a test sample status management function, making the system test results more consistent with the actual test results, effectively reducing system conflicts and deadlocks.

[0240] According to an embodiment of the present invention, an electronic device is provided. The electronic device in this embodiment may include one or more of the following components: a processor, a network interface, memory, non-volatile memory, and one or more application programs, wherein the one or more application programs may be stored in the non-volatile memory and configured to be executed by one or more processors, and the one or more programs are configured to perform the methods described in the foregoing method embodiments.

[0241] According to embodiments of the present invention, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a computer, causes the computer to perform the method described in any of the above embodiments.

[0242] According to embodiments of the present invention, a computer program product comprising instructions is also provided, which, when executed by a computer, cause the computer to perform a method in any of the above embodiments.

[0243] The specific embodiments described above further illustrate the purpose, technical solution, and beneficial effects of the present invention. It should be understood that the above description is only a specific 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.

Claims

1. A scheduling method for general-purpose testing instruments in an automated testing system for flexible manufacturing, characterized in that, The flexible manufacturing automated testing system includes a control computer equipped with a flexible scheduling software platform. The flexible scheduling software platform encapsulates general-purpose testing instruments, radio frequency routing and allocation devices, and samples under test into independent and parallel operating channels, and realizes status interaction through application programming interfaces. The method includes: A test task is obtained for the sample to be tested; wherein the test task includes multiple test items; wherein each test item is associated with the required test resources and the dependencies between it and other test items; Read the pre-configured delay time matrix; wherein, the delay time matrix records the delay time information of different test items under different signal transmission paths; For each test item, the corresponding expected delay time is determined based on its associated test resources, signal transmission path, and delay time information recorded in the delay time matrix. Based on the expected latency of each test item, the dependencies between test items, and the resource occupancy relationships between test items, a parallel test sequence is generated so that test items that do not have resource conflicts and satisfy the dependencies are executed in parallel. Tests are executed according to the control of test resources in the parallel test sequence.

2. The method according to claim 1, characterized in that, The steps of the test task for obtaining the sample to be tested include: Receive the sample identifier and test parameters input by the user; Based on the identifier of the sample to be tested, determine multiple test items to be executed from a predefined set of test items; Based on the predefined resource mapping relationship, the test resources associated with each test project are determined, and the dependencies and parameterized constraints between test projects that have resource competition are identified based on the parameters to be tested.

3. The method according to claim 1, characterized in that, The step of reading the pre-configured delay time matrix includes: Read the delay time matrix pre-configured in the extended configuration file; wherein the delay time matrix includes a test device submatrix, a test link submatrix, and a general test instrument submatrix; wherein each submatrix is ​​constructed with the input end of the signal transmission path as the row and the output end as the column, and each submatrix records at least the typical value of the delay time under the corresponding signal transmission path; wherein the delay time information of the delay time matrix for different test items and different signal transmission paths is the delay time information of the corresponding signal transmission path of each submatrix.

4. The method according to claim 3, characterized in that, The step of determining the corresponding expected delay time for each test item based on its associated test resources, signal transmission path, and delay time information recorded in the delay time matrix includes: For each test item, based on its associated test resources and signal transmission path, the delay time information corresponding to the signal transmission path is obtained from the test device submatrix, test link submatrix, and general test instrument submatrix, respectively. The delay time information of each submatrix is ​​combined and calculated to obtain the expected delay time of the test item under the corresponding signal transmission path.

5. The method according to claim 4, characterized in that, The step of combining and calculating the delay time information of each acquired sub-matrix to obtain the expected delay time of the test item under the corresponding signal transmission path includes: The delay time information of each submatrix is ​​sequentially flattened, processed by generating a Cartesian product grid, and added element by element to obtain the total link delay time of the signal transmission path, and the total link delay time is used as the expected delay time of the test item.

6. The method according to claim 5, characterized in that, The step of generating a parallel test sequence based on the expected latency of each test item, the dependencies between test items, and the resource occupancy relationships between test items, so that test items without resource conflicts and satisfying dependencies are executed in parallel, includes: Using the expected delay time of each test item as the job duration, the test items are initially sorted using the shortest job priority strategy to generate an initial test sequence; Based on the dependencies between test items and the occupancy of test resources, and combined with the channel status information obtained through the application programming interface, a priority value is assigned to each test item; wherein, the channel status information includes the real-time availability status of general test instruments, RF routing allocation devices, and the sample under test; The initial test sequence, the priority values ​​of each test item, and the dependencies between test items are taken as input. The heterogeneous earliest completion time algorithm is used for iterative optimization to generate a parallel test sequence. Each parallel execution unit in the parallel test sequence includes a set of test items that do not have resource conflicts and satisfy the dependencies. The parallel execution units are sorted according to the expected latency and priority values ​​of the test items.

7. The method according to claim 1, characterized in that, The step of controlling test resources to execute tests according to the parallel test sequence includes: According to the timing of the parallel test sequence, control commands are sent to the corresponding channels through the application programming interface to drive the general test instrument to generate test stimuli, control the RF routing and distribution device to switch signal paths, and obtain the test response of the sample under test. During the test, the device status information of each channel is obtained in real time through the application programming interface. By comparing the acquired device status information with the planned parallel test sequence, the execution of the test task is dynamically adjusted when an abnormal status or timing deviation is detected.

8. The method according to claim 1, characterized in that, The method further includes: After completing the tests according to the parallel test sequence, obtain the actual test time of each test item under the corresponding signal transmission path; The actual test time is written back to the position of the delay time information corresponding to the signal transmission path in the delay time matrix in the extended configuration file, so as to dynamically update the delay time matrix.

9. An automated testing system for flexible manufacturing, characterized in that, include: A control computer, the control computer being configured with a flexible scheduling software platform; wherein the flexible scheduling software platform is configured to execute the scheduling method as described in any one of claims 1 to 8; One or more general-purpose testing instruments are communicatively connected to the control computer; The radio frequency routing and distribution device is communicatively connected to the control computer and connected to the general-purpose test instrument and the sample under test, respectively, and is used to switch the test signal path under the control of the control computer. The flexible scheduling software platform encapsulates the general-purpose test instrument, radio frequency routing allocation device, and test sample into independent and parallel channels, and realizes state interaction through application programming interface.

10. An electronic device, characterized in that, include: A memory, and one or more processors communicatively connected to the memory; The memory stores instructions that can be executed by the one or more processors to cause the one or more processors to implement the method as described in any one of claims 1 to 8.

Images