Instrument resource pool construction scheme for automatic testing industry

Abstract

The invention discloses an automatic testing industry-oriented instrument resource pool construction scheme, which realizes automatic identification, unified management and efficient calling of instrument resources through instrument standardized description and dynamic link library packaging. The scheme comprises the following steps: (1) standardizing an instrument description language, and forming an instrument configuration file in an XML format; (2) packaging an instrument driver as a dynamic link library, including VISA, IVI and a non-standard instrument driver; (3) constructing an instrument automatic connection detection scheme, and realizing automatic creation of an instrument instance; (4) designing an instrument resource management scheme, and uniformly managing the life cycle of the instrument; and (5) constructing an instrument resource class, and completing dynamic creation of an instrument resource pool. The method has the following beneficial effects: (1) the compatibility is strong, and unified management of standard and non-standard instruments is supported; (2) the expansibility is high, and only a configuration file and a dynamic link library need to be expanded when an instrument is newly added; and (3) the standardization degree is high, a unified calling interface is provided, the underlying hardware difference is shielded, and the flexibility and maintenance efficiency of the test system are improved.

Description

Technical Field

[0001] A solution for building an instrument resource pool for the automated testing industry Background Technology

[0002] Measuring instruments are the executors of testing tasks in the automated testing industry. Establishing effective control of instruments within the testing system is a crucial aspect of automated testing. Most standard measuring instruments from mainstream instrument manufacturers adhere to VISA and IVI driver standards. These standards effectively manage instrument resources, shield underlying instrument differences, and utilize universal interfaces for instrument control. While standard drivers are convenient and standardized, they suffer from strong limitations due to their closed instrument ecosystem. Many testing scenarios require not only standard instruments but also non-standard instruments developed for specific scenarios to achieve the desired testing results. These non-standard instruments have varying communication methods and significantly different drivers, and lack standardized automatic release mechanisms for instrument resources. This situation leads most testing systems to directly hard-code instrument resources when using a combination of standard and non-standard instruments. During testing, programmers must consider the details and differences between instrument drivers at the code level and manually implement driver mapping and invocation when calling instrument resources. Hard-coding severely limits the versatility of testing systems; changes in hardware devices lead to changes in the underlying code. Furthermore, hard-coding wastes the flexibility and standardization inherent in VISA and IVI standard instrument drivers.

[0003] Therefore, the current automated testing industry needs an instrument resource pool construction solution with strong heterogeneous compatibility with underlying instrument drivers, standardized interfaces, and instrument resource management mechanisms. This solution should automatically identify and adapt to the communication protocols of different instruments, provide a unified driver interface, shield driver details for quick invocation, and ensure the efficient operation and flexible expansion of the testing system. Standardized resource pool management effectively avoids resource conflicts, improves instrument utilization, and reduces maintenance costs. Summary of the Invention

[0004] In the process of automatic instrument identification and resource construction in the automated testing industry, problems such as weak instrument compatibility, poor interface standardization, and difficulty in instrument expansion exist. This invention addresses these issues by providing a general instrument resource pool construction solution. This invention constructs an abstract instrument description method and an instrument driver encapsulation scheme based on a dynamic link library. It forms an integrated instrument resource pool construction process encompassing automatic instrument identification, instrument lifecycle management, and automatic instrument instance creation. It enables the dynamic construction of the instrument resource pool based on testing requirements and provides a standardized and unified instrument calling interface.

[0005] The described instrument resource pool construction scheme can be applied to automated testing platforms, playing a crucial role in the execution of test scripts. The implementation steps are as follows: First, standardize the instrument abstraction description method to form instrument configuration files. Second, encapsulate instrument functions using dynamic link libraries (DLLs) and standardize the structure of the DLL classes. Third, encapsulate DLL classes for VISA, IVI, and non-standard instruments. Fourth, construct an automated instrument connection detection process to construct instrument instances based on instrument model and address. Fifth, construct the instrument resource class structure, integrating the instrument connection detection and instrument instance construction processes to achieve dynamic creation of the instrument resource pool.

[0006] The features of this invention are:

[0007] (1) Good versatility: This solution is compatible with both standard and non-standard instruments. It not only supports standard instrument drivers for VISA and IVI, but also supports non-standard instrument drivers for various serial ports and proprietary assemblies.

[0008] (2) Strong scalability: When adding new instrument resources, there is no need to change the underlying code. Just add the relevant instrument abstract description in the instrument configuration file and insert the instrument library class into the instrument dynamic link library as needed to realize the expansion of instrument resources;

[0009] (3) High degree of standardization: All instrument resources provide a unified standard interface to realize instrument connection and testing, function call and life cycle management, make up for the imperfect management mechanism of non-standard instruments, shield the differences in underlying hardware, and provide users with an intuitive way to call instrument functions. Attached Figure Description

[0010] Figure 1 A physical instrument-driven framework based on an instrument resource pool.

[0011] Figure 2 Instrument configuration file classification.

[0012] Figure 3 Example of an instrument configuration file.

[0013] Figure 4 Dynamic link library structure division.

[0014] Figure 5 Dynamic link library call process.

[0015] Figure 6 VISA instrument structure.

[0016] Figure 7 IVI instrument driver mapping process.

[0017] Figure 8 IVI instrument structure.

[0018] Figure 9 Non-standard instrument structure.

[0019] Figure 10 Instrument connection and testing process.

[0020] Figure 11 Instrument resource lifecycle management.

[0021] Figure 12 Instrument resource structure

[0022] Figure 13 The process of constructing the instrument resource pool Detailed Implementation

[0023] The following is a detailed description of a method for constructing an instrument resource pool for the automated testing industry, provided by the present invention, with reference to the accompanying drawings.

[0024] Proper management and operation of physical instruments is a crucial aspect of the automated testing industry. Automatic instrument identification and the construction of an instrument resource pool are fundamental to the execution of test scripts by automated testing systems. The role of the instrument resource pool is explained below. Figure 1 As shown, the system obtains instrument requirements by parsing the test sequence, acquires the instrument model through instrument connection detection, and constructs an instrument resource pool by combining the model information and instrument configuration files. The resource management module binds instrument resources to the instrument resource pool according to the instrument requirements, and then schedules the corresponding functions in the instrument driver library through reflection calls to send control commands to the physical instruments, realizing the conversion of test tasks to physical instruments. The method of constructing the instrument resource pool consists of five steps, which are described in detail below.

[0025] Step one involves standardizing the instrument description to create an instrument configuration file. Based on the ATML standard with some improvements, the instrument is standardized in five aspects: attribute model, functional parameters, interface protocol, instrument driver, and dynamic constraints, resulting in an instrument configuration file. The instrument types are categorized into eight main types, such as oscilloscopes, multimeters, and signal generators. Within each category, specific instrument description files are created for each instrument model. Figure 2 As shown. Instrument configuration files are all written in XML format, which is standardized, clearly structured, and possesses strong versatility and flexibility. An example of an instrument configuration file for a certain model of multimeter is shown below. Figure 3 As shown.

[0026] Step two involves encapsulating the instrument's dynamic link library (DLL) to correspond with the instrument's configuration file. In software engineering, C#'s Dynamic Link Library (DLL) technology provides crucial support for modular design and code reuse. By encapsulating functional modules into independent assemblies, DLLs allow the main program to dynamically load and unload functional components at runtime, significantly improving system flexibility and maintainability. This invention requires unifying the encapsulation of standard and non-standard instrument drivers into a DLL with a unified structure and consistent calling method. The structure of the instrument DLL is as follows: Figure 4 As shown, each instrument dynamic link library needs to include constructors and destructors for creating and destructing instrument instances; detection functions to provide identification and detection solutions for non-standard instruments; and function calls to provide callable instrument functionalities. The calling flow of the instrument dynamic link library is as follows: Figure 5 As shown, when testing begins, the instrument connection is established first. At this point, the instrument's dynamic link library (DLL) first performs a parameterless construction, creating an empty instance and calling the connection detection function within this instance to obtain the instrument's model information. Then, carrying the instrument's model information, a parameterized construction is performed to establish a connection with the physical instrument, creating the actual instrument instance. During test operations, the corresponding function is called through the instance to obtain the test results. Upon completion of the test, the instrument instance is destructed.

[0027] Step 3: Encapsulate VISA standard instrument drivers. Drivers for instruments supporting the VISA standard are encapsulated to form instrument dynamic link libraries. VISA is a standard set of instrument control instructions, allowing developers to control programmable instruments using a standard SCPI string instruction set. In dynamic link library usage scenarios, drivers for VISA instruments can be built as follows: Figure 6 The library structure is shown below. In C#, the NationalInstruments.Visa library is used to call the relevant NI-VISA APIs. The Resource Manager allows users to start a session with a resource using ResourceManager.open() and end the session using ResourceManager.close(). VISA uses a unique address description string to identify each instrument resource. The Resource Manager allows users to write control commands using the FormattedIO.WriteLine() function and read the results returned by the instrument using the FormattedIO.Read() function. VISA also inherits the DeviceBase base class and IDeviceBase interface for lifecycle management, facilitating the system's management of instrument resources.

[0028] Step four: Encapsulate the IVI standard instrument driver. The IVI driver is an instrument driver architecture built on top of VISA. It provides an abstraction scheme based on function calls, further encapsulating the underlying SCPI instructions into more complex functional functions. To control IVI standard instruments, two layers of calls—class driver and dedicated driver—are required before finally mapping to the underlying VISA communication. IVI is designed this way to shield the differences in underlying drivers between instruments from different manufacturers, providing a unified instrument function call structure. An example of IVI driver mapping is shown below. Figure 7 As shown, taking the mapping of a multimeter DMM as an example, firstly, the instrument's model and address information are obtained through the instrument connection detection function of an empty instance, and a multimeter class driver instance is constructed simultaneously. Then, using the model and address as parameters, the path mapping information between the instrument model and the dedicated instrument driver is queried in the instrument configuration file. Based on this information, a dedicated instrument driver instance is created using reflection, completing the construction of the IVI instrument dynamic link library class. An example of the IVI instrument class structure is shown below. Figure 8 As shown, Config is a JSON file management class that records the mapping relationship between instrument models and drivers. AbstractDMMBase is an abstract class for instrument functions, inheriting from the DeviceBase base class for lifecycle management and the IDeviceBase interface. Internally, it implements the IIviDmm class driver interface and encapsulates the functions of a digital multimeter, including the acquisition of DC / AC voltage, DC / AC current, and resistance. These functions will expose interfaces for the test execution program to call. The DMM class is the main implementation of the instrument class, inheriting from the AbstractDMMBase class. In DMM, JSON file parsing, driver invocation, and dedicated driver creation are implemented. At the same time, separating the functional classes and the instrument classes through inheritance can effectively improve code utilization efficiency. When adjusting the instrument driver scheme for specific instruments, it is not necessary to repeatedly code the instrument functions.

[0029] Step 5: Package non-standard instrument drivers. In the automated testing industry, self-developed or non-standard equipment is used when performing certain special test operations. These often use self-developed function sets or rely on other communication protocols for control. The interface encapsulation for non-standard instruments needs to follow the standard form specified in this invention to achieve device scalability. Specifically, the non-standard instrument class must inherit the instrument lifecycle management method and interface, implement reliable instrument instance construction and destruction, and include a connection detection method that can return instrument model and address information, as well as function functions that implement the specific functions of the instrument. Taking a chip fixture using serial communication as an example, the fixture's library structure is as follows: Figure 9 As shown, the test fixture library still needs to meet the instrument lifecycle management rules defined by the DeviceBase base class and the IDeviceBase interface.

[0030] The CheckConnect() function uses GetPortNames() provided by System.IO.Ports to detect serial port devices, setSerialPort() is used to set specific rules for serial communication, and WritePort() is used for writing and receiving commands.

[0031] Step Six: Construct a unified instrument connectivity testing process. The construction of the instrument library class depends on information such as instrument model and address; therefore, reliable instrument connectivity testing is crucial for constructing the instrument library class. The instrument connectivity testing process of this invention is as follows: Figure 10 As shown, the automatic detection module uses the `FindResource` method as its entry point. After starting the detection, it first clears the internal test instrument resource cache information (cached using key-value pairs). Then, it sequentially identifies the resources of VISA and the instrument's dynamic link library. For standard VISA devices, a `ResourceManager` object is created based on `Ivi.Visa.dll` provided by the IVI Foundation. This object has basic methods for VISA-related processing, and then calls the `FindRsrc()` detection method to process USB, GPIB, TCPIP, and ASRL wildcard descriptors, obtaining a list of resource descriptors corresponding to the current connection. Since the IVI driver also establishes connections using NI-VISA address wildcards, this method can obtain the addresses of all devices supporting standard instruments. Then, through the `ResourceManager` instance, the identification information `*IDN?` is sent to the detected instrument. If the instrument is correctly connected, it will return a series of factory information. Then, it will resend a self-test command, requiring the instrument to perform a self-test and return the results. For instruments that pass both the query and self-test, various descriptive information such as model, category, and address mapping is recorded in the instrument's character set cache for subsequent resource calls. For non-standard instruments, the module will preload the descriptive information of all non-standard instrument dynamic link libraries in the instrument configuration file. Then, through reflection, it will locate the CheckConnect interface, execute the built-in detection method in the dynamic link library, and return the obtained descriptor list. If no instrument is detected, it will return null. Then, similar to standard instruments, the obtained instrument information is cached. At this point, the instrument detection and recognition module execution ends.

[0032] Step 7: Construct an instrument lifecycle management scheme. Standard instruments inherently possess mature lifecycle management schemes, but non-standard instruments struggle to guarantee a systematic instrument resource release mechanism, easily leading to abnormal resource occupation. Therefore, this invention uniformly formulates a complete lifecycle management scheme for both standard and non-standard instruments, ensuring the correct loading and release of instrument resources. In Steps 3, 4, and 5, VISA, IVI, and non-standard instruments all inherit from the DeviceBase base class and IDeviceBase interface used for lifecycle management. IDeviceBase defines the basic interface for device operation; any class implementing this interface must provide methods for checking the device connection status and closing the device connection. The CheckConnect() method checks the device connection status and returns a list of strings containing connection information; the specific connection checking logic is handled by the instrument class implementing this interface. Close() closes the connection with the device; the instrument must explicitly define the method for closing the connection to prevent resource leaks. DeviceBase is the base class for instrument lifecycle management; all instrument classes inherit from this class, exposing the Dispose function interface. Users can independently decide when to call this method to release instrument resources. The creation and release cycle of instrument instances is as follows: Figure 11 As shown, during the test case loading phase, an instrument instance is created through connection detection and constructor; during the test execution phase, the instrument instance method is called; and during the program termination phase, the instrument resources are released through the Dispose destructor.

[0033] Step 8: Construct the Instrument Resource Pool. After instrument identification is complete, for each connected instrument, a corresponding instrument resource instance will be created in the instrument resource pool to describe the current instrument resource. During the unit creation process, the instrument resource pool will access the instrument configuration file to qualitatively define the function and category of the current instrument, and register the basic information and status of the instrument. The description information of the instrument resource instance is as follows: Figure 12 As shown in the diagram. The `Id` records the instrument's descriptor information (VISA address for standard instruments, custom descriptor for non-standard instruments), `Type` records the instrument category information, `Model` records the specific model of the instrument, `Cabablity` records the instrument's functional description information, `Status` records the instrument's current status information (including idle, busy, and wrong), and `Handler` stores the instrument's operation handle, which can be used to call the instrument. The specific generation process of the instrument resource pool is as follows: Figure 13As shown, the process involves using the dynamic link library information in the instrument configuration file to call the specified CheckConnect() method to identify non-standard instruments, and using the VISA standard I / O library to identify standard instruments. Based on the generated instrument identification character set cache information, an instrument resource instance is created and its basic information is recorded. Simultaneously, the dynamic link library is called through the character set cache, and an instrument class library instance is created using reflection, establishing a connection with the physical instrument. The instrument class library call handle is saved to the corresponding instrument resource instance. Then, the functional description information in the instrument description file is queried to complete the instrument function information of the instrument resource instance. Once all detected instruments have successfully created instrument resource instances, the instrument resource pool is created and can be used by subsequent execution modules.

Claims

1. A scheme for constructing an instrument resource pool for the automated testing industry, characterized in that, Includes the following steps: Standardize the instrument description language, and use XML format to standardize the description of the instrument's attributes, functions, interfaces, drivers and constraints to form an instrument configuration file; Standardize instrument driver encapsulation. Based on dynamic link libraries, standardize the encapsulation of instrument driver library classes into three modules: construction and decomposition, connection and detection, and actual function. Dynamic link library encapsulation is performed for VISA drivers, IVI drivers, and non-standard instrument drivers; Develop an automated instrument connection and testing solution to automatically create instrument instances based on the detected instrument model and communication address; A systematic instrument resource management scheme is constructed, which utilizes the constructor and destructor methods in dynamic link library classes to realize the creation and release of instrument resources; Construct an instrument resource class and store information such as the handle of the instrument instance, instrument model, and function description in the instrument resource class; complete the creation of the instrument resource pool.

2. The instrument resource pool construction scheme for the automated testing industry according to claim 1, characterized in that, Standardize the instrument description language, specifically including: For eight common instrument models, such as oscilloscopes, multimeters, and signal generators, the ATML standard is used as the basis to standardize the description of the instruments from five aspects: attribute model, functional parameters, interface protocol, instrument driver, and dynamic constraints, forming an instrument configuration file.

3. The instrument resource pool construction scheme for the automated testing industry according to claim 1, characterized in that, Standardize instrument driver packaging, specifically including: Based on the dynamic link library of the C# language, the required instrument dynamic link library classes are packaged. The instrument dynamic link library classes need to contain constructors and destructors for creating and destructing instrument instances, detection functions for instrument identification and detection methods, and function functions for the actual functions of the instrument.

4. The instrument resource pool construction scheme for the automated testing industry according to claim 1, characterized in that, Instruments that encapsulate VISA drivers, IVI drivers, and non-standard instrument drivers, specifically including: For VISA-driven instruments, they are encapsulated into a VISA dynamic link library class. The main function of this library class is to send SCPI commands to the outside world and receive instrument return values ​​through the standard VISA protocol. For IVI-driven instruments, they are encapsulated into an IVI dynamic link library class. The main feature of this library class is that it uses a multi-layer mapping method based on the VISA protocol to shield the underlying differences between instruments from different manufacturers and provide users with a unified instrument operation method. For non-standard instruments, proprietary constructor and destructor functions, detection functions, and function functions are built in the library class according to the actual instrument driving method.

5. The instrument resource pool construction scheme for the automated testing industry according to claim 1, characterized in that, The system for automatically connecting and testing instruments includes: For standard instruments, the VISA standard resource manager is used to implement connection detection. For non-standard instruments, the detection function in the dynamic link library is called through the driver path in the instrument configuration file to perform connection detection. After successful connection, an instrument instance is created using the obtained instrument model and communication address information.

6. The instrument resource pool construction scheme for the automated testing industry according to claim 1, characterized in that, The system's instrument resource management solution includes: Each instrument library class inherits the DeviceBase base class and IDeviceBase interface for instrument lifecycle management. During the test case loading phase, instrument instances are created through connection detection and constructors. During the test execution phase, instrument instance methods are called. During the program termination phase, instrument resources are released through the Dispose destructor.

7. The instrument resource pool construction scheme for the automated testing industry according to claim 1, characterized in that, Constructing an instrument resource class and automatically creating instrument resources, specifically including: After instrument identification is completed, for each connected instrument, a corresponding instrument resource instance is created in the instrument resource pool. During the unit creation process, the instrument resource pool accesses the instrument configuration file to qualitatively define the function and category of the current instrument, and register the basic information and status of the instrument.

Images