Parallel testing technologies can improve test system performance by reducing processing time and increasing instrument use.
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 use.
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.
Figure 1. TestStand can automatically run a sequence in parallel using one of its parallel process models.
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 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. TestStand includes process models that automatically implement pipelining for test sequences and test UUTs in parallel.
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 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.
Figure 2. TestStand can automatically run a test sequence in parallel or use autoscheduling to test multiple units concurrently.
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.
Figure 3. The autoscheduling test sequence is set to run three tests.
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 use, it does not always help optimize instrument-intensive tasks. Optimizing instrument-intensive tasks requires increasing the use 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. 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, TestStand creates four different instances of the same sequence, one for each UUT, and automatically reorders the execution of tests to optimize instrument use and reduce test time.