Software Bus Architecture of Virtual Instrument Test Environment

Testing technology is the only engineering technology that runs through all stages of the product life cycle. The core technology of testing is software, which is the key to realizing commercial off-the-shelf (COTS). The software platform of automatic test equipment should take the principle of "interconnection, intercommunication, and interoperability" as the basic requirement to achieve the integration and sharing of test and diagnostic information.

Visual Instrument Test Environment (VITE) is an open universal test software platform product that supports the IEEE 1226 wide-area test environment (A Broad-Based Environment for Test) standard. It adopts the structure of soft bus (object bus) and uses the principle of object model drive to establish a transparent communication channel between various object model components and between the user and provider of the component. Its purpose is to achieve the independence of the development of the test program set of the automatic test system from the hardware platform, reflecting the convenience, flexibility, security and advancement of the system design. In the design of the software information model, it emphasizes system reconstruction or reorganization, and can be dynamically reorganized according to the different objects under test or test processes, reducing the cost of system reorganization.

1. Analysis of VITE Standard Architecture

The virtual instrument test environment VITE adopts an open object model driven architecture (Model Driven Architecture) to fully support various software interface standards in the product testing field to achieve the portability, reusability, interchangeability and interoperability of software components. The standard system is shown in Figure 1.

Figure 1 Virtual instrument test environment standard framework

In the entire standard system, according to the characteristics of product testing, it is divided into two levels of frameworks, namely information framework and system framework. All relevant component standards are hung on the framework soft bus in the form of plug-and-play functional modules.

Various information processing in the product testing process revolves around the information framework, including test requirement modeling data, test program documents, in-machine test data, diagnosis and maintenance data, instrument resource data and data exchange format data. The key is the Core Test Information Model defined in the IEEE 1226 standard, which fully describes the information entities of the test, test instructions, test requirements and other wide-area test fields. Each component standard is based on CTIM, and the expansion of CTIM is completed according to their own characteristics, so as to customize it to different application fields. The

specific test implementation revolves around the system framework, including various resource management services, runtime services, instrument drivers, diagnostic processing services, etc.

The system framework is responsible for providing information sources to the information framework and is the provider of information. The information framework issues information collection commands to the system framework according to the product test requirements, and receives and processes information.

The so-called framework is essentially a software environment designed to simplify application development and system management in special application fields. From another perspective, the framework is a kind of middleware in the software layer, which is located above the operating system and below the specific test application. Figure 2 shows the comprehensive set of standards in the ABBET Test Foundation Framework.

Figure 2 ABBET test basic standard framework

The standardized framework allows test applications and tools to be supported in heterogeneous platforms implemented on the ABBET framework services. The standards are organized around three axes representing test subjects, test resources, and test environments.

Test subject standards, represented by the horizontal axis of the figure, support the acquisition and reuse of test subject information. Test subject information captures the description of the test subject design and test requirements, which can avoid secondary development during initial development, maintenance, and re-deployment of test applications. Test subject information also includes diagnostic knowledge that can be accessed during the test process.

Test resource standards, represented by the vertical axis, apply to test resources and information. Test resource control standards support access to system services such as instrument configuration and data acquisition. Test resource information standards support the specification of test application resource requirements and test instrument capabilities. These standards support the adaptation of test applications to changes in test equipment configuration.

Environment-related standards, represented by the oblique axis, support the interchange and re-deployment of test applications between heterogeneous test environments. Test information is exchanged in a neutral, implementation-independent format that is well suited for data import and export services.

2. VITE Implementation Architecture

The architecture of the open virtual instrument test environment contains a variety of standard open software interface relationships. Software function modules exchange information through these interfaces, and these function modules with standard interfaces constitute the basic test framework.

VITE is based on object-oriented components and has designed and implemented several functional components in accordance with the principles of information framework and system framework. The specific structure is shown in Figure 3.

Figure 3 VITE structure

A component is a well-defined, independent, reusable binary code. It can be some functional modules, encapsulated object classes, software frameworks, software system models, etc. In the current object-based component software architecture, "components" refer to binary codes and data that can be easily inserted into languages, tools, operating systems, and network software systems.

The soft bus is also called the object bus or ORB (object request broker). Its purpose is to provide a transparent communication channel between components or between component users and component providers. The application execution, diagnostic display, test system and other components in the figure are "software integrated circuits (ICs)" attached to the soft bus.

The soft bus is the core that connects applications, various objects, services, and object tool sets. It can divide each component object element in an orderly manner to achieve distributed software integration and plug-and-play in applications. It includes two levels of relationships: 1) The relationship between the "definition" of object methods and services and their "implementation". Through the interface definition language OMG IDL, we can obtain standardized and universal object method and service definitions. With the help of the soft bus, these definitions can be truly implemented in any programming language and code module. This division helps to exchange specific software codes, programming languages ​​and versions. 2). The relationship between the requesting "client" and the responding "server". The client's request for other object methods and services is not directly passed to the requested server, but transferred to the soft bus, which monitors the location and status of the server and determines the way to bind the service. This relationship helps to integrate distributed objects across platforms and protocols.

These two relationships can ensure that components communicate through the bus and solve the interoperability problem between components. Each component is connected to the bus through a component communication unit (also called an adapter). The adapter component solves the interoperability and data exchange problems between components that do not know each other. The data component object sent from the adapter to the bus can be automatically recognized by any other adapter, and the data component object can be appropriately adjusted by the installer during installation to change the function and structure of the service component to adapt to new requirements. The user interface component provides presentation services, and the service component provides functional services.

Combined with the VITE standard architecture division described in Section 2 and the relationship between the test subject, test resources and test environment, the entire VITE implementation is divided into five conceptual layers.

The first layer is the test information layer, which mainly describes the product under test to obtain relevant information on product design and maintenance tests, as well as special requirements for its testing. The model editing component in Figure 3 mainly completes the functions of this layer.

The second layer is the test requirements and strategy layer, which provides standard information entities for the test requirements, test modes and diagnostic knowledge of the UUT (unit under test), with the purpose of generating efficient test programs and reliable data. The application execution component, diagnostic engine component, database engine component, etc. in Figure 3 mainly complete the functions of this layer.

The third layer is the user application layer, which is mainly used to help develop TPS programs and defines the operation interface corresponding to the test execution. The test execution includes test selection, test sequence selection, diagnostic interaction, access to user interface components, and access to data logs and file operations. The application execution component, diagnostic display component, etc. in Figure 3 mainly complete the functions of this layer.

The fourth layer is the test resource management layer, which provides a basic interface for comprehensive management of test system resources and supports the ability to perform independent ATE tests under certain specific ATE conditions. Its purpose is to allow instruments manufactured by different manufacturers and different types of instruments to be used in the same test program to complete their respective functions. The COTS test language component in Figure 3 mainly completes the functions of this layer.

The fifth layer is the instrument driver (control) layer. This layer mainly provides various bus standards and instrument interfaces that ATE can use, such as IEEE488, SCPI, VISA, IVI, etc. The COTS instrument driver component in Figure 3 mainly completes the functions of this layer.

III. VITE Core Information Model Structure

The basic information model of the VITE information framework is based on the core information model structure CTIM. Its goal is to describe the test of one or more products and provide a way to exchange test information between different systems. Its description can be independent of the tester, which can support test reuse between different platforms and environments. The

core test information model is an information model that describes test behavior. It must have the following functional characteristics:

a) Describe the expected product behavior characteristics

b) Define test requirements

c) Define resource capabilities and requirements

d) Define the behavior of the test strategy

e) Guide system diagnosis

There are five entities in the CTIM model:

a) Location: The location captures the location where the event occurs. The location is not further defined in the current model, and will be further defined in the future when it is bound to product information.

b) Behavior: The behavior captures the time when the event occurs. Used to identify the time interval of an event, defined by its start and stop attributes.

c) Signal: A signal captures an event. Signal types include signal-oriented symbols and other standard programming types (such as integers, real numbers, or Boolean types).

d) Constraint: Constraints define rules that constrain or limit the range of signal values.

e) Time: Time in the model is only used to support the definition of behavioral entities. It is a subclass of the variable (defined below) entity and is used to define the types of the start and stop attributes of the behavioral entity.


Figure 4 VITE's core test information model



The various information components described in the previous section of this article are based on CTIM or are extensions of CTIM. All components can be supplemented with further details based on CTIM to customize them to different test application areas.

4. Interchangeable Virtual Instrument IVI Model

Under the guidance of the system framework, VITE's instrument driver adopts the IVI (Interchangeable Virtual Instruments) model in accordance with the requirements of the standard system. The IVI model is a driver design standard developed by the IVI Foundation based on VPP (VXI Plug & Play) technology. It realizes the interchange between some general instruments by defining class drivers and special drivers, shortens the program development time, and improves the system's operating performance.

The purpose of the IVI standard is to allow users to integrate standard IVI components into different software and hardware systems. It supports various interfaces, including GPIB, VXI, PXI, Serial, USB, Ethernet, Firewire, and PC plug-in, allowing similar instruments (with different interfaces) to be interchangeable. The use of this technology can support instrument interchange, reduce system costs, and improve system operating performance and configuration capabilities.

The IVI model uses a special component of the IVI-COM communication engine to ensure dynamic interchange of instruments. The application calls the logical name of IVI, and the engine is responsible for matching the logical name of the configuration library to connect the actual physical instrument.

Therefore, after extensively collecting information on specific application requirements of the test system, following the IVI standard, summarizing the usage of various general test instruments, and using object-oriented implementation methods, we established various IVI instrument classes, encapsulated the properties, methods, and events of the instruments, and were able to inherit and reconstruct them. This allows the replacement of test instruments without modifying the test program. As long as the functions of the test instruments are the same, the test instruments can be interchanged without modifying the test program.

The soft bus architecture of the virtual instrument test environment integrates a series of standards such as test engineering project management elements (maintenance demonstration, test requirements analysis, diagnostic capability allocation and design, system integration and testing, test capability maturity, etc.), embedded test elements (BIT/BITE), external test elements (maintenance level, automatic test equipment, test program set, personnel training, database, technical information collection and analysis, logistics and technical support). In the construction of the VITE platform, it is fully guaranteed that: first, it is based on test requirements analysis, second, it implements the idea of ​​integrated diagnostic information support system (IDSS), and third, it strictly implements standardized procedures and follows and adopts relevant international and national standards. Such ideas and methods have benefited us a lot in constructing a universal test platform.