A resource modeling method for complex electronic equipment automatic test system

Abstract

This application discloses a resource modeling method for an automated test system for complex electronic equipment. The method includes analyzing the physical resources corresponding to the automated test items to be tested, clarifying the functional test requirements for the required resources; determining whether a database contains the required communication bus model, data protocol model, and registration information for the logical and physical models of the required resources; and modeling any models not included by developing standard components and registering database information; and visually configuring the test resources required by the automated test system, clarifying the logical models and configuration parameters of the test resources required for different test cases, and generating a test configuration XML file. This application enables users to quickly build automated test systems.

Description

Technical Field

[0001] The present application relates to the field of automatic testing technology, and in particular to a resource modeling method for an automatic testing system of complex electronic equipment. Background Art

[0002] Electrical performance is a core functional characteristic of complex electronic equipment. Testing of electrical performance is crucial both during the equipment manufacturing phase and during post-delivery maintenance and operation. It is a crucial step in ensuring equipment quality consistency and integrity. Traditional manual testing can no longer meet the high-density, long-duration, and complex testing requirements of electronic equipment. Automatic test systems (ATS) have become the most economical and efficient testing method. With the development of advanced technologies such as computers, automation, and instrumentation and control, automatic test systems have evolved from specialized to general-purpose, and from desktop instruments with standard interfaces to open test systems centered around computer software. Currently, with the continuous changes in internal and external environments, test requirements and scenarios are also evolving rapidly, posing new challenges to automatic test systems: rapid construction and flexible versatility. The core foundation lies in the scalability and adaptability of various models of test resources, which involves test resource modeling methods.

[0003] Currently, mainstream general-purpose automatic test systems are built based on the ATML (Automatic Test Markup Language) standard. The ATML standard primarily uses a signal-oriented approach to describing test resources within a test system. It provides comprehensive specifications for basic information about the object under test, test strategies and methods, signal descriptions, test program sets, test results, and test run times, as well as a standardized data method for exchanging information between test components. ATML test resources primarily refer to instrument signal resources. The InstrumentDescription defines the test resource's information, such as the resource name, control bus type, resource address, and input / output capabilities.

[0004] The current resource modeling methods based on ATML automatic test systems and other test systems still have the following problems when dealing with complex electronic equipment testing:

[0005] 1. Low configuration efficiency. Most general-purpose test systems use signals to define test resources, such as the types and parameters of signals that an instrument can generate or measure. This definition allows the test system to adapt to a wider range of scenarios. However, in the field of complex electronic equipment testing, the signal types required for testing are very limited (primarily RF pulse signals), making signal-level modeling complex and inefficient.

[0006] 2. Lack of a unified external interface and insufficient scalability. Existing technologies typically model and manage the product under test (DUT), test equipment, and test instruments separately. For complex electronic equipment testing, these three types of resources share essentially the same communication bus and calling methods, making unified abstract modeling and management more suitable. This enhances scalability while also facilitating the calling and development of test suites.

[0007] Therefore, the existing technology is not suitable for resource modeling of automatic test systems for complex electronic equipment. Summary of the Invention

[0008] In order to overcome the challenges of low resource allocation efficiency, dynamic adaptability and insufficient scalability of existing technologies in dealing with complex electronic equipment automatic testing systems, the present application provides a resource modeling method for complex electronic equipment automatic testing systems, which can help build a more universal, flexible and highly reliable automatic testing system that supports rapid iteration and complex testing scenarios.

[0009] This application discloses a resource modeling method for an automatic test system for complex electronic equipment, which includes:

[0010] Step 1: Analyze the physical resources corresponding to the automatic test items to be tested, and clarify the relevant functional test requirements of the resources required for testing; physical resources include the product under test, test instruments, and test equipment; related functions include communication buses, data protocols, product under test functions, instrument functions, and equipment functions;

[0011] Step 2: Determine whether the database contains the registration information of the communication bus model of the required resource. If not, develop the corresponding program component according to the IDevBUS interface standard, register the model through the registration tool, and store the registration information in the DevBUS data table of the SQLite database to generate the communication bus model. The registration information includes the communication bus name, component name, component address index, and communication bus description.

[0012] Step 3: Determine whether the database contains the registration information of the data protocol model of the required resource. If not, develop the corresponding program component according to the IDataProtocol interface standard, register the model through the registration tool, and store the registration information in the DataProtocol data table of the SQLite database to generate the data protocol model. The registration information includes the protocol name, component name, component address index, and protocol description.

[0013] Step 4: Determine whether the database contains the registration information of the logical model of the required resource; if not, develop the corresponding program component according to the IlogicalDevice interface standard, register the model through the registration tool, and store the registration information in the logicalDevice data table of the SQLite database to generate the logical model. The registration information includes the logical name, category, component name, component address index, and function description;

[0014] Step 5: Determine whether the database contains the registration information of the physical model of the required resource. If not, use a visual method to configure the physical parameters of the resource, including the mapped logical model, communication bus model, and data protocol model. Register the model using a registration tool and store the registration information in the Device data table of the SQLite database to generate a physical model. The registration information includes model, manufacturer, logical mapping information, and physical parameter information.

[0015] Step 6: Configure the resources required for the automatic test system test, clarify the logical model of the test resources required for different test cases and their configuration parameters, and form a test configuration XML file. This XML file describes the test sequence and the functional operations of each step of the test sequence on the test resources, configuration parameter names, parameter types and parameter values.

[0016] Furthermore, the step 5 further includes:

[0017] After selecting the mapped logical model, if the function is configurable, the specific function instructions that need to be configured will be displayed on the visual interface. For instruments, the SCPI commands corresponding to each instrument function will be configured. For the product under test, the operation commands corresponding to the control function of the product under test will be configured. The configured commands will be written to the FunCommandList data table in the SQLite database for storage.

[0018] Furthermore, after step 6, the method further includes:

[0019] Before starting to test complex electronic equipment, the automatic test system is initialized. Based on the actual physical connection of the system, the program components of the communication bus are first loaded and the communication bus ports are instantiated. Then, based on the instruments, equipment, tested products and their bus ports required in the system default configuration, specific physical resources and their mapped logical resources are instantiated to form physical resource pools and logical resource pools.

[0020] During the test execution process, logical resources rather than physical resources are allocated from the logical resource pool according to the test configuration file, and are dynamically allocated on demand rather than statically bound; resources are released after the test is completed.

[0021] Furthermore, the test resources of complex electronic equipment are divided into test instruments, test equipment and tested products; test instruments include signal sources, spectrum analyzers, oscilloscopes, vector network analyzers, and radar simulators, which are used to provide signal excitation and signal measurement for testing; test equipment includes turntables, target trackers, liquid cooling equipment, and switch matrices, which are used to provide various conditions or environments for product functional performance testing; the tested product is the object to be tested, and the tested product is classified as a test resource, which is uniformly abstracted and modeled with the test instruments and test equipment; different test resources are connected to the automated test system through a unified interface, without the need to modify the program, and the hardware and software are deeply decoupled.

[0022] Furthermore, the test resources are modeled in a hierarchical abstract manner, namely, the communication bus layer, the data protocol layer, the functional logic layer, and the physical layer;

[0023] The communication bus layer is a communication bus model that provides standardized protocols for data transmission, reception, and control.

[0024] The data protocol layer is a data protocol model used to parse the data stream of the communication bus into standard messages required for testing;

[0025] The functional logic layer is a logical model that abstracts physical test instruments, test equipment, and tested products into logical resources, and abstracts and defines functional logic based on their test capabilities.

[0026] The physical layer is a physical model that corresponds to the test resources of a specific physical domain and is used to define the categories, attributes, and capabilities of different types of physical test instruments, test equipment, and products under test.

[0027] All test resources have a communication bus, which is uniformly abstracted into an externally callable interface specification IDevBUS. The interface specification IDevBUS includes communication bus information, driver type, communication events, and data buffering. Program components of different types of communication buses call the underlying driver to implement data transmission and control functions.

[0028] Furthermore, the data protocol model includes string text parsing, character stream message parsing, and image recognition parsing. The data protocol program component is developed based on a unified abstract interface specification IDataProtocol. The interface specification IDataProtocol includes protocol type, message type, protocol format, and unpacking and packaging methods.

[0029] Furthermore, the logical model performs functional abstract modeling based on the unified abstract interface specification IlogicalDevice. The interface specification IlogicalDevice includes basic information, communication bus, data protocol, and functional description. According to the requirements of the functional description, a set of functional function interfaces are defined, and functional program components are designed and developed to implement the program logic of the functional functions according to the functional characteristics.

[0030] Furthermore, the logical model is hierarchically modeled based on functional similarity, and is broadly classified by instruments, equipment, and tested products;

[0031] The instrument includes basic functions and core functions. Basic functions include command sending and status query functions, which are available in every test instrument. Core functions are further subdivided and modeled according to simple signal source, complex signal source, spectrum analyzer, single-channel power supply, dual-channel power supply, vector network analyzer, and oscilloscope. The core functions of simple signal source include frequency setting, repetition rate setting, pulse width setting, modulation mode switch, signal on / off, and power setting. The core functions of complex signal source include frequency agility, repetition rate staggering, polarization modulation, frequency diversity, and phase coding.

[0032] The product under test includes basic functions and core functions. Basic functions include communication transceiver and test initialization. Communication transceiver will output parsed data based on the message type parsed by the protocol and the communication event registered by the communication bus, and send the command data generated by the protocol parsing package through the communication bus. Test initialization will initialize the product under test to make it testable. Core functions can be further subdivided and modeled according to the specific product under test model. Different products under test can be distinguished according to functional groups with different test characteristics.

[0033] The equipment can be further subdivided and modeled according to the turntable, target tracker, liquid cooling equipment, and switch matrix; the turntable includes basic functions and core functions. The basic functions include turntable enable, start and stop functions, limit settings, and zero settings. The core functions are further subdivided and modeled according to the two-dimensional turntable and three-dimensional turntable; the core functions of the three-dimensional turntable include pitch angle setting, horizontal angle setting, roll angle setting, acceleration setting, and movement speed setting.

[0034] Furthermore, the physical model and logical model of the test resource are in a many-to-many relationship. One physical model may correspond to multiple logical models, and multiple physical models may correspond to one logical model.

[0035] Due to the adoption of the above-mentioned technical solution, this application has the following advantages: By applying this application in the development, construction, upgrade and maintenance of complex electronic equipment automatic test systems, a total of nearly 500 various models of test resources have been established, including more than 20 communication bus models, more than 80 instruments, more than 40 devices, and logical and physical models of more than 200 tested products. The modular and standardized modeling method and the modeling method based on the visual interface and XML configuration have increased the efficiency of test resource modeling by 60% and the model reuse rate by 80%. The universal automatic test platform developed based on the technology of this application has shortened the development cycle of the automatic test system from one month to about one week, effectively supporting the demand for fast and reconfigurable automatic test construction. Currently, more than 200 automatic test systems have been developed based on this application, and their application verification has been completed in the automatic testing of various types of electronic equipment. In addition, the upgrade and maintenance of the test system due to the replacement of hardware resources can be quickly adapted through the visual configuration method without modifying the underlying code, supporting the rapid iteration of the test system and complex test scenarios. BRIEF DESCRIPTION OF THE DRAWINGS

[0036] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the following briefly introduces the drawings required for use in the description of the embodiments. Obviously, the drawings described below are only some embodiments recorded in the embodiments of the present application. For ordinary technicians in this field, other drawings can also be obtained based on these drawings.

[0037] Figure 1 A schematic flow chart of a resource modeling method for a complex electronic equipment automatic test system according to an embodiment of the present application;

[0038] Figure 2 This is a schematic diagram of hierarchical abstract modeling of test resources according to an embodiment of the present application. DETAILED DESCRIPTION

[0039] The present application is further described with reference to the accompanying drawings and embodiments. The embodiments described are only a part of the embodiments of the present application, not all of the embodiments. All other embodiments obtained by ordinary technicians in this field should fall within the scope of protection of the embodiments of the present application.

[0040] See also Figure 1 The present application provides an embodiment of a resource modeling method for an automatic test system of complex electronic equipment, which includes:

[0041] S101: Analyze the physical resources corresponding to the automatic test items to be tested, and clarify the relevant functional test requirements of the resources required for the test; physical resources include the product under test, test instruments, and test equipment; related functions include communication buses, data protocols, product under test functions, instrument functions, and equipment functions;

[0042] S102: Determine whether the database contains the registration information of the communication bus model of the required resource. If not, develop the corresponding program component according to the IDevBUS interface standard, register the model through the registration tool, and store the registration information in the DevBUS data table of the SQLite database to generate the communication bus model. The registration information includes the communication bus name, component name, component address index, and communication bus description.

[0043] S103: Determine whether the database contains the registration information of the data protocol model of the required resource. If not, develop the corresponding program component according to the IDataProtocol interface standard, register the model through the registration tool, and store the registration information in the DataProtocol data table of the SQLite database to generate the data protocol model. The registration information includes the protocol name, component name, component address index, and protocol description.

[0044] S104: Determine whether the database contains the registration information of the logical model of the required resource; if not, develop the corresponding program component according to the IlogicalDevice interface standard, register the model through the registration tool, and store the registration information in the logicalDevice data table of the SQLite database to generate the logical model. The registration information includes the logical name, category, component name, component address index, and function description;

[0045] S105: Determine whether the database contains the registration information of the physical model of the required resource. If not, use a visual method to configure the physical parameters of the resource, including the mapped logical model, communication bus model, and data protocol model. Register the model using a registration tool and store the registration information in the Device data table of the SQLite database to generate the physical model. The registration information includes model, manufacturer, logical mapping information, and physical parameter information.

[0046] S106: Configure the resources required for the automatic test system test, clarify the logical model of the test resources required for different test cases and their configuration parameters, and form a test configuration XML file. The XML file describes the test sequence and the functional operation of each step of the test sequence on the test resources, configuration parameter name, parameter type and parameter value.

[0047] Optionally, the S105 further includes:

[0048] After selecting the mapped logical model, if the function is configurable, the specific function instructions that need to be configured will be displayed on the visual interface. For instruments, the SCPI commands corresponding to each instrument function will be configured. For the product under test, the operation commands corresponding to the control function of the product under test will be configured. The configured commands will be written to the FunCommandList data table in the SQLite database for storage.

[0049] Optionally, after S106, the method further includes:

[0050] Before starting the test, the system is initialized. According to the actual physical connection of the system, the program components of the communication bus are first loaded and the communication bus port is instantiated. Then, according to the instruments, equipment, tested products and their bus ports required in the system default configuration, specific physical resources and their mapped logical resources are instantiated to form a physical resource pool and a logical resource pool.

[0051] During the test execution process, logical resources are allocated from the logical resource pool instead of physical resources according to the test configuration file, and resources are allocated dynamically on demand instead of statically bound. Resources are released after the test is completed.

[0052] Optionally, the test resources of complex electronic equipment are divided into test instruments, test equipment and tested products; test instruments include signal sources, spectrum analyzers, oscilloscopes, vector network analyzers, and radar simulators, which are used to provide signal excitation and signal measurement for testing; test equipment includes turntables, target trackers, liquid cooling equipment, and switch matrices, which are used to provide various conditions or environments for product functional performance testing; the tested product is the object to be tested, and the tested product is classified as a test resource, which is uniformly abstracted and modeled with the test instruments and test equipment; different test resources are connected to the automated test system through a unified interface, without the need to modify the program, and the hardware and software are deeply decoupled.

[0053] Alternatively, see Figure 2 ,carry out hierarchical abstract modeling of test resources, i.e. modeling them into communication bus layer, data protocol layer, functional logic layer and physical layer;

[0054] The communication bus layer is a communication bus model that provides standardized protocols for data transmission, reception, and control.

[0055] The data protocol layer is a data protocol model used to parse the data stream of the communication bus into standard messages required for testing;

[0056] The functional logic layer is a logical model that abstracts physical test instruments, test equipment, and tested products into logical resources, and abstracts and defines functional logic based on their test capabilities.

[0057] The physical layer is a physical model that corresponds to the test resources of a specific physical domain and is used to define the category attributes and capabilities of different types of physical test instruments, test equipment, and tested products.

[0058] Optionally, all test resources are equipped with a communication bus, which is uniformly abstracted into an externally callable interface specification IDevBUS. The interface specification IDevBUS includes communication bus information, driver type, communication events, and data buffer. Program components of different types of communication buses call the underlying driver to implement data transmission and control functions.

[0059] Optionally, the data protocol model includes string text parsing, character stream message parsing, and image recognition parsing. The data protocol program component is developed based on a unified abstract interface specification IDataProtocol. The interface specification IDataProtocol includes protocol type, message type, protocol format, and unpacking and packaging methods.

[0060] Optionally, the logical model performs functional abstract modeling based on a unified abstract interface specification IlogicalDevice. The interface specification IlogicalDevice includes basic information, communication bus, data protocol, and functional description. According to the requirements of the functional description, a set of functional function interfaces are defined, and functional program components are designed and developed to implement the program logic of the functional functions according to the functional characteristics.

[0061] Alternatively, see Figure 2 , hierarchical modeling is performed on the logical model according to functional similarity, and the major categories are classified by instruments, equipment, and tested products:

[0062] The instrument includes basic functions and core functions. The basic functions include command sending and status query functions, which are possessed by every test instrument. The core functions are further subdivided and modeled according to simple signal source, complex signal source, spectrum analysis, single power supply, dual power supply, vector network analyzer, and oscilloscope; the core functions of simple signal source include frequency setting, repetition rate setting, pulse width setting, modulation mode switch, signal on and off, and power setting; the core functions of complex signal source include frequency agility, repetition rate difference, polarization modulation, frequency diversity, and phase coding.

[0063] The product under test includes basic functions and core functions. The basic functions include communication transmission and reception, and test initialization functions. Communication transmission and reception will complete the output of parsed data based on the message type parsed by the protocol and the communication event registered by the communication bus, and will send the command data generated by the protocol parsing group package through the communication bus. Test initialization will initialize the product under test to make the product under test reach a testable state; the core functions can be further subdivided and modeled according to the specific model of the product under test, and different products under test are distinguished according to functional groups with different test characteristics.

[0064] The equipment can be further subdivided and modeled according to the turntable, target tracker, liquid cooling equipment, and switch matrix; the turntable includes basic functions and core functions. The basic functions include turntable enable, start and stop functions, limit settings, and zero settings. The core functions are further subdivided and modeled according to the two-dimensional turntable and three-dimensional turntable; the core functions of the three-dimensional turntable include pitch angle setting, horizontal angle setting, roll angle setting, acceleration setting, and movement speed setting.

[0065] Optionally, the physical model and the logical model of the test resource are in a many-to-many relationship, and one physical model may correspond to multiple logical models, and multiple physical models may correspond to one logical model.

[0066] For ease of understanding, this application also provides a more specific embodiment:

[0067] The method of the present application is used in the resource modeling process of the automatic test system of a certain electronic equipment. According to the development and implementation steps described in the invention summary, the working process is as follows:

[0068] (1) Test requirements analysis

[0069] The test system in this example needs to be tested, and the test resources required are: 1 signal source and 1 spectrum analyzer; 1 two-dimensional turntable; and 1 product under test.

[0070] (2) Communication bus modeling

[0071] Communication bus requirements: All instruments are program-controlled via TCP / IP; the turntable is program-controlled via a serial port; and the product under test communicates via the DDS bus. Comparing the registration information for the communication buses in the database revealed that only the DDS bus was unregistered and required modeling. Based on the .NET framework, a DDS program component was developed according to the IDevBUS interface standard. The model was registered using a registration tool, and the DDS bus registration information was stored in the DevBUS data table in a SQLite database. This generated a DDS communication bus model. The registration information included the communication bus name [DDS bus], component name [DDSBus.dll], component address index [.. / / component], and a communication bus description [DDS bus uses a publish-subscribe model and is commonly used for the communication bus of the product under test].

[0072] (3) Data protocol modeling

[0073] Data protocol requirements: The instrument and turntable are program-controlled via commands and do not require data parsing. The product under test uses a unique character stream message parsing method. By comparing the registered data protocol model information in the database, it was determined that the registered character stream message parsing model was not compatible with the communication protocol of the product under test, requiring customized development. Based on the interface standard, a customized protocol parsing program component was developed according to the communication protocol of the product under test. The model was registered using a registration tool, and the registration information was stored in the DataProtocol table of the SQLite database to generate a customized character stream data protocol model.

[0074] (4) Logical Modeling

[0075] Logical model requirements: Four types of functions, including simple signal source, spectrum analyzer, two-dimensional turntable and DUT test. By comparing the registration information of the logical models in the database, the logical models of simple signal source, spectrum analyzer and two-dimensional turntable have been registered and no development is required. The logical model of DUT test requires personalized development. Develop the corresponding program components according to the IlogicalDevice interface standard, using the .NET framework; define a set of functional interfaces according to the requirements of DUT test: communication reception and transmission, test initialization, radar library distribution, BIT self-test, receiving frequency band setting, product power on and off, and implement the program logic of the functional functions in the program components. Register the model through the registration tool, store the registration information in the logicalDevice data table of the SQLite database, and the logical model of the DUT test can be generated.

[0076] (5) Physical resource modeling

[0077] Physical model requirements: The instruments used are the E8257D signal source and N9000B spectrum analyzer, a ZT1 turntable, and electronic equipment of this type. Comparing the registered physical model information in the database reveals that the E8257D physical model is not registered. A visual method is used to configure the physical model information, such as: device model [E8257D], manufacturer [Keysight], logical model [Simple Signal Source / Complex Signal Source], and device information [High-Performance Vector Signal Source]. Furthermore, if the mapped logical model is selected as a simple signal source, specific SCPI commands can be further configured through the visual interface. These commands are stored in the FunCommandList data table in the SQLite database, generating the physical model of the E8257D signal source.

[0078] (6) Test parameter configuration

[0079] Configure the test resources required by the automated test system through a visual interface. For example, consider a single indicator test. Configure simple signal source parameters, setting the frequency from 1 GHz to 3 GHz, with a 200 MHz step, a 200 µs pulse width, and a 12 µs repetition rate. Configure 10 XML nodes, each with the signal source input parameters. Configure the DUT test parameters, set the test initialization command parameters, and configure the functional command in the first XML node.

[0080] (7) Instantiation and dynamic allocation of test resources

[0081] After the system hardware is connected, the test software is opened. Before the test begins, the communication bus program component is loaded and communication bus ports such as "COM3" and "192.168.1.2:6701" are instantiated. Based on the system default configuration, specific physical resources and their mapped logical resources are instantiated to form physical and logical resource pools. The physical resource pool includes the E8257D-ID1234, N9000B-ID7800, ZT1-ID002, and DUT1-K9211001. The logical resource pool includes one simple signal source, one complex signal source, one spectrum analyzer, one 2D turntable, and one DUT1 test. During test execution, logical resources are dynamically allocated from the logical resource pool based on the test configuration file. For example, for one indicator test, the logical resources of the simple signal source mapped to the E8257D-ID1234 physical entity are allocated. During the test, the test resources are occupied and released after the test ends.

[0082] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present application and not to limit them. Although the present application has been described in detail with reference to the above embodiments, ordinary technicians in the relevant field should understand that the specific implementation methods of the present application can still be modified or replaced by equivalents. Any modification or equivalent replacement that does not depart from the spirit and scope of the present application should be included in the scope of protection of the claims of the present application.

Claims

1. A resource modeling method for an automatic test system for complex electronic equipment, characterized in that: include: Step 1: Analyze the physical resources corresponding to the automatic test items to be tested, and clarify the relevant functional test requirements of the resources required for testing; physical resources include the product under test, test instruments, and test equipment; related functions include communication buses, data protocols, product under test functions, instrument functions, and equipment functions; Step 2: Determine whether the database contains the registration information of the communication bus model of the required resource. If not, develop the corresponding program component according to the IDevBUS interface standard, register the model through the registration tool, and store the registration information in the DevBUS data table of the SQLite database to generate the communication bus model. The registration information includes the communication bus name, component name, component address index, and communication bus description. Step 3: Determine whether the database contains the registration information of the data protocol model of the required resource. If not, develop the corresponding program component according to the IDataProtocol interface standard, register the model through the registration tool, and store the registration information in the DataProtocol data table of the SQLite database to generate the data protocol model. The registration information includes the protocol name, component name, component address index, and protocol description. Step 4: Determine whether the database contains the registration information of the logical model of the required resources; If not, develop the corresponding program components according to the IlogicalDevice interface standard, register the model through the registration tool, and store the registration information in the logicalDevice data table of the SQLite database to generate the logical model. The registration information includes the logical name, category, component name, component address index, and function description. Step 5: Determine whether the database contains the registration information of the physical model of the required resource. If not, use a visual method to configure the physical parameters of the resource, including the mapped logical model, communication bus model, and data protocol model. Register the model using a registration tool and store the registration information in the Device data table of the SQLite database to generate a physical model. The registration information includes model, manufacturer, logical mapping information, and physical parameter information. Step 6: Configure the resources required for the automatic test system test, clarify the logical model of the test resources required for different test cases and their configuration parameters, and form a test configuration XML file. This XML file describes the test sequence and the functional operations of each step of the test sequence on the test resources, configuration parameter names, parameter types and parameter values.

2. The method according to claim 1, characterized in that The step 5 further comprises: After selecting the mapped logical model, if the function is configurable, the specific function instructions that need to be configured will be displayed on the visual interface. For instruments, the SCPI commands corresponding to each instrument function will be configured. For the product under test, the operation commands corresponding to the control function of the product under test will be configured. The configured commands will be written to the FunCommandList data table in the SQLite database for storage.

3. The method according to claim 1, characterized in that After step 6, the method further includes: Before starting to test complex electronic equipment, the automatic test system is initialized. Based on the actual physical connection of the system, the program components of the communication bus are first loaded and the communication bus ports are instantiated. Then, based on the instruments, equipment, tested products and their bus ports required in the system default configuration, specific physical resources and their mapped logical resources are instantiated to form physical resource pools and logical resource pools. During the test execution process, logical resources rather than physical resources are allocated from the logical resource pool according to the test configuration file, and are dynamically allocated on demand rather than statically bound; resources are released after the test is completed.

4. The method according to claim 1, wherein Testing resources for complex electronic equipment are divided into test instruments, test equipment, and products under test. Test instruments include signal sources, spectrum analyzers, oscilloscopes, vector network analyzers, and radar simulators, which provide signal stimulus and measurement for testing. Test equipment includes turntables, target trackers, liquid cooling equipment, and switch matrices, which provide various conditions or environments for product functional performance testing. The product under test is the object to be tested. It is classified as a test resource and is uniformly abstracted and modeled together with the test instruments and test equipment. Different test resources are connected to the automated test system through a unified interface without the need to modify the program, and the hardware and software are deeply decoupled.

5. The method according to claim 1, wherein Conduct hierarchical abstract modeling of test resources, namely, modeling them into communication bus layer, data protocol layer, functional logic layer, and physical layer; The communication bus layer is a communication bus model that provides standardized protocols for data transmission, reception, and control. The data protocol layer is a data protocol model used to parse the data stream of the communication bus into standard messages required for testing; The functional logic layer is a logical model that abstracts physical test instruments, test equipment, and tested products into logical resources, and abstracts and defines functional logic based on their test capabilities. The physical layer is a physical model that corresponds to the test resources of a specific physical domain and is used to define the category attributes and capabilities of different types of physical test instruments, test equipment, and tested products.

6. The method according to claim 5, characterized in that All test resources have a communication bus, which is uniformly abstracted into an externally callable interface specification IDevBUS. The interface specification IDevBUS includes communication bus information, driver type, communication events, and data buffering. Program components of different types of communication buses call the underlying driver to implement data transmission and control functions.

7. The method according to claim 5, characterized in that The data protocol model includes string text parsing, character stream message parsing, and image recognition parsing. The data protocol program components are developed based on the unified abstract interface specification IDataProtocol. The interface specification IDataProtocol includes protocol type, message type, protocol format, and unpacking and packaging methods.

8. The method according to claim 5, characterized in that The logical model is based on the unified abstract interface specification IlogicalDevice for functional abstract modeling. The interface specification IlogicalDevice includes basic information, communication bus, data protocol, and functional description. According to the requirements of the functional description, a set of functional function interfaces are defined, and functional program components are designed and developed to implement the program logic of the functional functions according to the functional characteristics.

9. The method according to claim 5, characterized in that The logical model is hierarchically modeled according to functional similarity, and is classified into instruments, equipment, and tested products in broad categories; The instrument includes basic functions and core functions. Basic functions include command sending and status query functions, which are available in every test instrument. Core functions are further subdivided and modeled according to simple signal source, complex signal source, spectrum analyzer, single-channel power supply, dual-channel power supply, vector network analyzer, and oscilloscope. The core functions of simple signal source include frequency setting, repetition rate setting, pulse width setting, modulation mode switch, signal on / off, and power setting. The core functions of complex signal source include frequency agility, repetition rate staggering, polarization modulation, frequency diversity, and phase coding. The product under test includes basic functions and core functions. Basic functions include communication transceiver and test initialization. Communication transceiver will output parsed data based on the message type parsed by the protocol and the communication event registered by the communication bus, and send the command data generated by the protocol parsing package through the communication bus. Test initialization will initialize the product under test to make it testable. Core functions can be further subdivided and modeled according to the specific product under test model. Different products under test can be distinguished according to functional groups with different test characteristics. The equipment can be further subdivided and modeled according to the turntable, target tracker, liquid cooling equipment, and switch matrix; the turntable includes basic functions and core functions. The basic functions include turntable enable, start and stop functions, limit settings, and zero settings. The core functions are further subdivided and modeled according to the two-dimensional turntable and three-dimensional turntable; the core functions of the three-dimensional turntable include pitch angle setting, horizontal angle setting, roll angle setting, acceleration setting, and movement speed setting.

10. The method according to claim 5, characterized in that The physical model and logical model of test resources have a many-to-many relationship. One physical model may correspond to multiple logical models, and multiple physical models may correspond to one logical model.

Images