Design of General Automatic Testing Software Platform

Traditional automatic test systems lack universality, and the most fundamental solution is standardization. This paper takes the ABBET (A BroadBased Environment for Test) standard as the main standard and other international standards related to ATS (Automatic Test System) as the supplementary standard. It adopts a software hierarchy that conforms to the standard description and uses software design technologies such as COM components and CORBA to develop a signal-oriented universal automatic test system software platform. The use of the international standard ATS development model can, on the one hand, maximize the instrument independence and TPS (Test Program Set) universality of signal-oriented testing; on the other hand, this development model simplifies the difficulty of software system architecture, improves the reliability and compatibility of the system, and provides a unified interface for external diagnostic methods.

With the rapid development of technologies such as electronic science and material science, the complexity of high-tech products such as aerospace equipment and military weapon systems is increasing. Traditional manual inspection and maintenance methods can no longer meet the support and guarantee requirements of modern equipment. ATS (automatic test system) is gradually becoming a necessary guarantee for the reliable operation of complex systems and equipment.

However, my country currently does not have a unified testing technology system and management system, nor does it have a mandatory testing software system standard. The data structures used by various software are different, and the system models vary greatly, resulting in a wide variety of test software systems and low-level repeated development. In addition, the test software operating environment is not standardized, and the test languages ​​used are not unified or the versions are different, resulting in the non-universality of system test software, resulting in defects such as long development cycle, repeated development, poor portability, and weak exchange capabilities, which greatly affects the user's mastery and use of it. The above factors make the universalization, standardization, modularization, and serialization of the test system software platform far behind the international level, becoming the primary factor restricting the development of my country's automatic test system.

This paper focuses on the standard architecture of the ABBET test environment and the key technologies for achieving the universality of the software platform. The software system framework defined by ABBET is refined into five operational software layers (test strategy and requirements layer, test program layer, resource management layer, instrument control layer, and hardware layer). The functions of each layer are developed separately using the relevant standards to achieve communication between layers, and finally a signal-oriented universal automatic test software platform is developed.

1 Overview of test-related international standards

The IEEE 1226 ABBET standard is a software architecture specification that enables standardized data exchange and interoperability between software platforms built according to this architecture. ABBET focuses on describing and standardizing test software, formally describing test information from the perspective of information modeling, and eliminating barriers to transplantation, sharing, and application of test information between levels. In software design, it emphasizes system reconstruction or reorganization, and can dynamically reorganize according to the different objects under test or test processes, reducing the cost of system reorganization. However, the ABBET standard only proposes the ATS framework and describes the relationship between each level in the test development process. How to implement the functions of these levels in specific applications and realize a complete signal-oriented automatic test system requires designers to develop it themselves.

IEEE 1226.3 and the IVI instrument driver specification describe how to maximize instrument interchangeability.

The IEEE 1641 standard provides the ability to describe and control signals based on COM technology, allowing users to choose any development platform and programming language that supports COM, and can easily achieve portability of test programs.

IEEE 1671 provides an open standard for information transmission, which enables information to be transmitted between test programs of different test instruments, thus facilitating the portability and interoperability of TPS and the interchangeability of instruments.

The IEEE 1232 standard defines the ATS fault diagnosis service interface. It provides basic diagnostic services and allows various diagnostic methods to be added to the ATS, greatly improving the ATS fault diagnosis level.

2 Test Platform Software Architecture

2.1 ABBET structural hierarchy

The ABBET structure consists of a collection of classes created from a single class in the base structure. This base provides a reference structure of basic and main classes. This can be specified at different levels to create a generic test environment (framework) or a dedicated test application.

The ABBET standard architecture is divided into three levels: basic framework structure, extended framework structure and application.

The organization of the basic framework is similar to a collection of interfaces, each of which is related to one or more ABBET component standards, or to industry standards published by IEEE or other recognized organizations. It defines basic interfaces suitable for different stages in the life cycle of a product system.

A TAF is a collection of reusable categories that fulfill the requirements of a specific application domain. Each TAF serves a specific category, technology, resource, or requirement in the test subject. An extension framework is composed of one or more such application frameworks (TAFs).

ABBET provides direct access to applications from development tools and TAF. An application may use one or more frameworks to provide access to the classes that execute the application. Figure 1 shows the ABBET structural hierarchy, and Figure 2 illustrates the ABBET architecture divided according to operations, functions, and organization related to the ABBET component standard.

Figure 1 ABBET structure hierarchy Figure 2 ABBET system architecture [page]

Table 1 lists the layered model of the test environment and the design and testing standards required for each layer.

Table 1 Testing pan-environmental layered testing standards

2.2 Test platform software structure

To realize universal ATS, the resource demand description, virtual resource model, and real resource drive are all based on signal interface, and the instrument-based drive approach should be abandoned. The key to the portability of TPS and the interchangeability of instruments lies in the construction of the drive model.

Using signal-oriented driver components, when virtual resources are mapped to real signals, the instrument exposes the signal interface to the software system instead of the specific instrument. ABBET uses the TFF signal model to describe test requirements, which is independent of the specific test system.

FIG3 shows the structure of the signal-oriented test system software platform based on the TFF signal model.

Figure 3 Software platform structure

The test strategy and requirement layer is used for users to configure test information, such as test requirements and test strategies.

The test program layer completes the test process design and converts the test requirements and test process into test code. The TFF signal model component library provides signal models for TPS development in different programming development environments.

The resource management layer completes the mapping from virtual resources to actual resources and executes specific test processes. The programming language interface transforms the test signal resource requirements expressed in various programming languages ​​into virtual resources. The resource model library is used to model specific resources. The driver component drives the actual resources.

The instrument control layer fully complies with the IVI instrument driver specification and uses IVICOM technology to drive the actual test instruments.

3 Discussion on key technologies

3.1 RTS operation mechanism

RTS is the core component in the resource management layer. It first performs syntax checking and compilation on the test program and converts it into entries corresponding to the signal model (signal type, UUT port connection, signal range, signal attribute, method call, etc.); then it starts the query engine to locate the virtual resources to the real resources; next, it calls the driver engine to execute the UUT port and signal port connection algorithm according to the connection model, and executes the operations specified by the signal model to realize the test process.

The RTS mechanism ensures that virtual resources are completely isolated from real resources. Virtual resources only propose test requirements and do not involve ATS instrument configuration. RTS is always in working state during TPS operation, capturing TPS test requirements, controlling the driving components to drive the actual instruments to execute the test process, and exiting only after TPS execution is completed.

3.2 Implementation of Virtual Resource Management Mechanism

The resource management layer is the core layer of the platform. The function of the "virtual resource manager" module in the RTS component is to analyze specific signals and then select and drive specific instruments. The virtual resource management structure is shown in Figure 4.

3.2.1 Virtual Resource Modeling

The virtual resources in the platform adopt the TFF signal modeling method and component technology. According to the object-oriented concept, the signals are divided into several limited categories: constant, ramp, random, exponential, pulse, step, decaying sine, trapezoid, noise (non-periodic), sine curve, triangle, square wave, standard sine, and other waveforms (periodic). Each type of signal is modeled with a unified parameter attribute table for easy instantiation.

3.2.2 Signal driver components

The instrument driver component model adopts the TFF signal driver component model, which includes signal information (name and logical address, etc.), signal attributes, signal capabilities, signal ports and their signal driver methods. This corresponds to the needs of virtual resources one by one, which is conducive to the mapping of virtual resources to real resources. At the same time, it also contains information such as signal name, logical address and its capabilities, which is provided to RTS for finding real resources and positioning. Specifically, the signal driver component is implemented upward through methods and events in the signal model, and the operation of the underlying instrument is implemented downward using a general repackaged specific instrument driver.

3.2.3 Resource model implementation

The test resource model provides ATS with data models and management for system resource configuration and connection paths with the unit under test. The resource model includes device model, configuration model and adapter model. The model is established and represented using a database to make the model standardized and easy to modify.

The device resource model DM describes the relevant information of specific resources and is the basis for the resource manager to select instruments according to signal requirements. The device model is described in the database through the device record table and the device function table: the device record table describes the relevant information of all test equipment in the ATE system; the device function table records the signal generation/test capabilities of the instruments and equipment in the test system. [page]

The configuration CM model defines the input and output relationship of the switch resources of a specific test system. It includes the connection issues of various switch resources and analog buses, so it has a more complex connection relationship. The adapter model AM defines the connection relationship between switch resources and UUT, which is similar to the configuration model. It uses a database table to model and cooperate with the test system to achieve instrument matching, channel selection and connection of the entire path.

Figure 4 Virtual resource management structure

3.3 Optimal Path Selection Problem

In actual applications, there are many types of specific hardware devices, and each type of hardware device can realize multiple signal functions. There is more than one way to connect switches and pathways, which brings up the problem of RTS's selection of instruments and pathways.

The theory of state graph search can be used in test path search, and there are many mature algorithms at present. According to the actual situation of the problem and the demand for the optimal solution, the A* algorithm is selected as the basic solution to the problem of optimal test path selection. The A* algorithm handles the selection of nodes by calculating the estimated value. In the actual problem of optimal test path selection, the constraint conditions, node position and other information are used to reduce the number of nodes before calculating the estimated value, which greatly reduces the blindness of the search and quickly finds the best path.

Conclusion

The test on the existing platform proves that the design of this software platform is feasible. Designing the test system software platform based on international standards solves the problems of instrument interchangeability and TP portability, embodies the object-oriented concept, and realizes the universality of the test system software platform.

References

[1] IEEE Std 12261998. IEEE trialuse standard for A Broad Based Environment for Test (ABBET),overview and architecture，199906.

[2] IEEE Std 1226.31998. IEEE standard for software interface for resource management for A BroadBased Environment for Test (ABBET)，199806.

[3] IEEE SCC20. ATLAS 2000 Architecture Document. Revision 3.0, 199706.

[4] Object Management Group. The Common Object Services Specification, OMG Technical Committee Document formal/980705,199807.

[5] Jurcak Tom.Test programming in an ABBET signal oriented environment[C]//Proceedings of AUTOTESTCON, 1996: 3639.

[6] Liu Jinning, Meng Chen, Yang Suochang, et al. A new generation of test language based on signal components - ATLAS2K and its application research [J]. Measurement and Control Technology, 2004 (9): 5760.

[7] Yu Gongjing, Ma Haodong, Yang Guangzhi, et al. Soft bus architecture of virtual instrument test environment [J]. Computer Measurement and Control, 2006(2):141143.

[8] Luo Jin, Su Zhenzhong, Meng Chen. Research on standardization of automatic test system software design[J]. Instrument Technology, 2009(8):7173.

[9] Wang Suning, Yang Shiyuan. Instrument-independent test system integration technology[J]. Electrical Measurement and Instrumentation, 2004, 41(465):3840.

[10] Guang Fu, Wang Houjun, Tian Shulin, et al. Modern Testing Technology[M]. Chengdu: University of Electronic Science and Technology of China Press, 2003.

[11] Yang Xisheng, Tian Shulin, Huang Jianguo. Application of ABBET in radar integrated test system software design[J]. China Test Technology, 2006, 32(4):101104.

[12] Xia Xin. Research on virtual resource management technology in testing pan-environment[D]. Wuhan: Huazhong University of Science and Technology, 2006.