Academic Company Events NI Developer Zone Support Solutions Products & Services Contact NI MyNI

Document Type: Instrumentation Newsletter
NI Supported: Yes
Publish Date: Feb 19, 2008


Feedback


Yes No

Related Links - Developer Zone

Related Links - Products and Services

Optimizing Test System Performance with Parallel Testing Technologies

3 ratings | 4.33 out of 5
Read in | Print

Parallel testing technologies can improve test system performance by reducing processing time and increasing instrument utilization. 

Using multicore processors, you can reduce test time by running processor-intensive tasks faster. Instrument-intensive tasks, on the other hand, require techniques such as autoscheduling, which reorders the execution of tests to reduce test time by increasing instrument utilization.  

For a test application to use multicore processors, the application’s complete software stack must be multithreaded. The three most common components of an automated test software stack are the test executive, application software, and instrument drivers.  


[+] Enlarge Image

Figure 1. NI TestStand can automatically run a sequence in parallel using one of its parallel process models.

Test Executive

A test executive is the overarching application that manages all the components of a test system and controls its execution. If the test executive is not multithreaded, the whole test system runs on a single processor core even if it is testing multiple units under test (UUTs). On the other hand, multithreaded test executives, such as those developed with NI TestStand test management software, can generate different threads for each UUT. Each of these threads can run on different processor cores (see Figure 1).  

Creating a multithreaded test executive does not automatically translate to better performance. The test executive must also execute different operations concurrently. In the sequential testing portion of Figure 2, a multithreaded application is running tests for four UUTs in separate threads sequentially. This type of execution does not take advantage of parallel multicore processing resources. None of the operations are executed in parallel.

Multithreaded test executives that run operations in parallel can be challenging to develop due to the need to share resources, such as instrumentation or unit handlers, across different threads. Two threads cannot access the same resource concurrently. Pipelining is one method for implementing a test executive that executes operations in parallel. As seen in the sequential testing example of Figure 2, pipelining offsets the start of each thread’s execution by one test. By offsetting the start of each thread’s execution, test sequences can run concurrently, reducing test times by more than 50 percent. Pipelining reduces the most test time in sequences where tests take approximately the same amount of time and require a separate resource for each test. NI TestStand includes process models that automatically implement pipelining for test sequences and test UUTs in parallel.  

Application Software

Application software must also be multithreaded to take advantage of multicore processors. Implementing multithreaded applications is possible with most programming languages today but varies in difficulty depending on the language. For example, graphical programming languages such as NI LabVIEW are inherently parallel and automatically generate multiple threads depending on the application’s architecture. On the other hand, text-based programming languages such as C require you to explicitly create, manage, and control threads, which can be more challenging and error-prone as application complexity increases.  


[+] Enlarge Image

Figure 2. NI TestStand can automatically run a test sequence in parallel or use autoscheduling to test multiple units concurrently.

Instrument Drivers

For a driver to be used in a multithreaded application, it must be thread-safe and reentrant. For a driver to be thread-safe, it must operate correctly if two threads call it concurrently. In addition, the driver must be reentrant. If a driver is thread-safe but not reentrant, it will become a bottleneck by allowing only one thread to use the driver at a time. In contrast, reentrant and thread-safe drivers can create different instances of the driver for true parallel execution.  


[+] Enlarge Image

Figure 3. The autoscheduling test sequence is set to run three tests.

What about the Instruments? 

During automated tests, most of the time is spent in measurement, communication, and other instrument-intensive tasks. Although taking advantage of multicore processors helps optimize processor utilization, it does not always help optimize instrument-intensive tasks. Optimizing instrument-intensive tasks requires increasing the utilization of the available resources by running tests on idle test resources. For example, in Figure 2, the parallel testing example could be further optimized by running tests during the idle time at the beginning of each UUT’s execution. By reordering tests to take advantage of idle resources, as shown in the autoscheduling diagram in Figure 2, you can reduce test time by up to 60 to 75 percent compared to a sequential execution. Autoscheduling requires tests to be capable of executing in any order and be independent of prior test results. NI TestStand supports autoscheduling through development components that you can add to test sequences. Figure 3 shows a test sequence that implements the autoscheduling example demonstrated in Figure 2.  

The sequence consists of a main “Auto Schedule” group, which includes three different “Use Auto Schedule Resource” groups. Each “Use Auto Schedule Resource” group defines a different instrumentation resource that must be shared across the different UUTs. Inside each “Use Auto Schedule Resource” group, the sequence calls a LabVIEW VI that executes each test. When executing this test sequence, NI TestStand creates four different instances of the same sequence, one for each UUT, and automatically reorders the execution of tests to optimize instrument utilization and reduce test time.  

Santiago Delgado

Santiago Delgado is the product manager for NI TestStand and NI Requirements Gateway. He holds a bachelor’s degree in management information systems from the University of Nebraska – Lincoln.  

Read a white paper on optimizing automated test applications for multicore processors.

This article first appeared in the Q1 2008 issue of Instrumentation Newsletter.

3 ratings | 4.33 out of 5
Read in | Print

Reader Comments | Submit a comment »

 

Legal
This material is protected under the copyright laws of the U.S. and other countries and any uses not in conformity with the copyright laws are prohibited, including but not limited to reproduction, DOWNLOADING, duplication, adaptation and transmission or broadcast by any media, devices or processes.