Working through test-program sets and drivers, test executives let engineers organize tests into logical sequences. They provide user interfaces for test technicians and store test results for analysis.

Manufacturers of electronic and electromechanical devices rely on test instruments to generate stimuli and measure responses. While manually performing tests on the engineering bench might work for some early prototypes, it’s often not given the sheer complexity of today’s designs and certainly not feasible for production. That’s where automation comes in. Using computers, software, and switching systems lets you automate tests and store test results for analysis.

Because today’s products are so complex, you need to logically organize test sequences. You may also need to perform similar tests on several designs. After all, you surely don’t want to write new software each time if possible. You also need an organized process to collect, store, and transmit test data. Therefore, a modular approach to automated test software is essential. At the top of that software chain sits the test executive.

Before explaining what you can do with a test executive, let’s start with the hardware that does the actual work.

What’s in an ATE system?
Figure 1 shows a typical (automated test equipment (ATE) hardware setup consisting of test instruments, switches, and a DUT. Many ATE systems include a test fixture and perhaps an interface test adapter (ITA) from the switches to the fixture.

ATE systems need a computer and several software layers that reside between a test operator and the DUT. These layers provide abstractions that shield test operators from the details. They also provide programming interfaces so that engineers developing tests and test sequences don’t necessarily need to work with every instruction that an instrument supports. Instead, engineers can focus on the task of testing.

The details of communicating with an instrument typically fall to an instrument driver. “What is an instrument driver and why do I need one?” explains how instrument drivers create a layer of abstraction between a test engineer writing a test programming set (TPS) and the instrument itself. The TPS tells the driver what it wants the instrument to do. For example, measure an analog voltage without having to deal with the instrument’s exact syntax.

What does a TPS do?
A TPS typically contains a sequence of steps needed to perform a specific test, which often involves communication with more than one instrument. A simple but typical sequence might include:

1. 1. Set a signal source to a specific amplitude and frequency.
   2. Set a digitizer to the appropriate range.
   3. Set the switches to connect the instruments to the DUT.
   4. Collect the test results and take appropriate action.
   5. Set the instruments back to a quiescent, stable state and disconnect the DUT from the instruments.

Test engineers program a TPS using a test-programming language (LabVIEW, ATEasy), general-purpose language (C, C++), or scripting language (Python).

What is a test executive?
At the top of the software stack sits the test executive (Figure 2), which contains the test operator’s user interface and controls the overall test sequence.

A test executive typically contains two main modules:

1. 1. 1. • Test development environment
         • Test execution engine

In some applications, these modules are separated and function as two GUIs. In other cases, a single GUI covers both.

Test-development environments come in many flavors. They let test engineers create, develop, and organize TPSs. Some test-development environments require programming knowledge while others let users create test sequences through visual block diagrams.

A test execution engine (Figure 3) executes TPSs by communicating with ATE instrumentation and the DUT (or DUTs) through drivers. A test execution engine takes an input from a built/compiled TPS and executes the test. A test executive can target multiple UUTs sequentially or in parallel. Semiconductor testing is an example where a test executive stimulates multiple DUTs simultaneously. Depending on the test executive, a GUI could let the operator monitor the test flow status, read the measurement results, and report pass/fail tests. In some cases, the test executive could store results in a database and present the test outcome as a report. Some environments can interface with automated documentation tools as well as post-processing applications.

Engineers can implement test organization within the test executive differently depending on the platform. The common goal, however, is to create a test flow that includes a series of desired tests starting with setup, which will include all the routines and calls that initialize the test instruments. Once the test executive establishes communication with the instruments, it can move on the executing a test.

Next comes the main test. Typically, it will include all the routines to stimulate the DUT with and measure its responses. Obviously, test looping, branching off based on measurement results, and other conditional execution techniques are available based on the functionality offered a test executive. After all the main tests run, the final module should be responsible for the reset and cleanup. In this stage, all the instruments should be brought to their quiescent state so there are no longer any active signals present in the station. All switches should be open, thus breaking the paths between the ATE and the DUT. Other functions in this stage can finalize the data recording and make the proper input for reports and data analyses.

How does the test executive communicate with test applications, drivers, test hardware, and the DUT?
Engineers can apply different approaches on how to handle communication between the modules of the test system. In cases where there is a separation between the test-development environment and the execution engine, you would need to compile/build the project first before invoking the execution engine and commencing the test. The main input into the compile/build process is the TPS source code. Once the source gets built into the binary code, the execution engine will take over and start the execution. The code must also have the information that the TPS requests such as data for signals and routines requested in the TPS. That data lets the execution engine call the appropriate instrument driver. In cases where there is no separation between the test development environment and the execution engine, all the compilation and building processes are not visible to the user and they occur in real time when the test commences.

After the engine properly allocates a TPS signal to an ATE instrument, it makes a call to the driver. As a result, the ATE instrument gets instructed to perform a task described in a TPS. An example of such a task could be applying an AC signal. The driver that the engine selects will call the allocated instrument, in this case, a function generator producing a signal with a specified amplitude, shape, and frequency. The ATE connects to the DUT through the switching instruments and ITA. To route the voltage signal from the function generator to a particular DUT test pin, specific relays in the switching device will close, establishing the path between the ATE instrument and the DUT.

Instrument drivers used in today’s test stations typically support interchangeable virtual instrument (IVI) drivers, or some other plug-and-play type that relies on Virtual Instrument Software Architecture (VISA). Test executives routinely support bus interfaces such as GPIB, PXI, VXI, serial (RS232/RS485), Ethernet/LXI, and USB.

Can you write your own test executive?
You can write your own test executive but it’s a large undertaking. At Astronics, we use commercial test executives as well as those we develop in-house, depending on customer specifications. For example, we use two platforms developed in-house: PAWS Developer’s Studio, which uses Abbreviated Test Language for All Systems (ATLAS) as a TPS language, and ActivATE test software, which uses C# or VBScript to develop test sequences. The standard options available on the market provide a robust and complete package that typically took decades of development effort to bring them to their current form. The objective of the universal and well-designed test executive is to improve the productivity of test engineers and developers through modern graphical interfaces, different programming languages, reuse, and a host of other techniques. Test executives enable customization, backward compatibility, and legacy protection, which reduces the project lifecycle costs.

Test executives reduce the risk of ATE and software obsolescence. During a test system’s lifecycle, which can exceed 20 years, there will be a need to re-host the test station to the current Operating System (OS). New test instruments often require an updated instrument driver. The modular architecture and ability to decouple the TPSs from hardware and driver dependency can make the re-host and upgrade process more manageable, seamless, and cost-effective.

Typically, each TPS undergoes a validation process before formal release. The need to adjust and re-validate the TPS because of the ATE upgrade or OS re-host is time-consuming, costly, and should be avoided or minimized. Some test executives do better in this area than others. These objectives are not easily achievable when developing your own test executive unless you have many experienced developers available. Creating your own test executive will be more of a dedicated solution, which will most likely fulfill the simple test requirements for a given scenario but will lack flexibility and support for long lifecycles. Well-architected test executives can easily interface with third-party tools such as test-requirement editors, test-program generators, and automated documentation tools, which might be an additional argument against developing your own.

Commercial test executives have a universal approach, which lets you design test stations that target various DUTs. Creating your own Test Executive solution is certainly a challenging and time-consuming task.