Parallel testing (multiple devices-under-test (DUT) testing simultaneously), can improve your testing strategy by enhancing product flow, reducing aggregate test times, and improving instrument usage. However, when not implemented effectively, can bring about a slew of challenges. Addressing these challenges often requires a combination of robust test infrastructure, careful test design, and ongoing maintenance and monitoring to ensure that parallel testing delivers its intended benefits.
With NI TestStand, developing parallel systems becomes significantly easier, reducing much of the associated effort and making parallel systems highly cost-effective.
There are three commonly implemented techniques for Parallel Test:
1. Multiple Computer Systems.
The most "traditional" systems have many computers operating in parallel, synchronizing and sharing common data across the network.
The major benefit of the "traditional" test architecture is that each machine operates effectively independently, simplifying the programming. The system only needs to operate on one DUT at a time, and it only operates with one test, or instruction, at a time. The limitation of this system occurs when you need significant synchronization across the network, because you need to understand the network topology and the OS architecture to communicate between computers. This solution is also the most expensive because you compound all of the hardware requirements for each tester, including computers, instruments, network routers, and expected maintenance and upgrades.
2. Systems that use multiple processes carrying out parallel tasks.
In this scenario, you use a single computer so many processes occur in parallel, in which a process may be an instance of an executable program. The OS isolates the memory of each process, which prevents any program that malfunctions from crashing the whole system. However, because the memory is isolated, sharing data and driver instances is difficult and often inefficient. To communicate between processes, you must use mechanisms such as shared memory, pipes, and out-of-process ActiveX servers. (See Figure 1.) If you use software components that do not come with source code, you might not have these options.
3. Multiple Threads.
This type of parallel system uses a single process that creates and destroys separate instances of threads as it moves through its execution.
In this scenario, the application operates as a single process and thus operates in a single memory location. Normally this process starts operation with a single Main thread that executes all the steps, or sub-sequences, as it progresses through the sequence. However, you can configure this type of process to create and destroy separate threads at any time. Threads have a major benefit over processes -- because they exist within a single process, they can share data and other resources far better. (See Figure 2.)
Introducing a more efficient parallel testing technique utilizing NI TestStand models
Acculogic’s Test Programming Services (TPS) team uses National Instruments TestStand to customize your unique test program. With the new models introduced in TestStand 2.0, we are able to produce a framework in which our tests run for Parallel and Batch. The models define the order, or flow, of the test system, defining and controlling common tasks such as reporting, database reporting, logging in and out, and serial number information. They also provide placeholders for custom tasks such as pre and post-UUT tasks. For example, you can control the fixture to load and unload the device before and after testing. The models are themselves sequences, so you have free access to define custom sequence structures.
The parallel and batch models differ in the way they handle multiple boards. The batch model defines that the boards are synchronized at the start and end of the test sequence, and also potentially between. This is a natural model for testing a batch of products undergoing environmental screening, where sets of units are tested together inside a temperature chamber or a vibration rig. The parallel model, by comparison, tends to act on the units completely independently. This behavior is much more applicable to end-of-line functional test, where a number of units may arrive at different times, providing there is a test fixture to hold the DUT then the test system starts to cycle through it. We show a flow diagram for these models below.
Using these models to define a test system now becomes a relatively simple proposition, first selecting the required configurations. With the options now configured, the test sequences, or steps, which have been developed in the sequence editor now run in parallel with an initial dialogue for entering the four serial numbers. The four instances of the tests are each run on a separate thread, all of which are created automatically by the batch model. These threads are synchronized at the start of the execution, and then, they are resynchronized before generating the reports and being destroyed by the model. 
This sequence execution scenario is obviously very simplistic and assumes that all tests need to be run in parallel. However, this is not the case for most test systems where, potentially, you want only one of the threads to execute the test step. For example, we have a set of three tests to be run on a batch of DUTs: Configure Chamber, RF Test, and Vibration Analysis. For the Configure Chamber test, we may want only one thread to execute, as it is talking to a PLC, and if all four threads spoke it may confuse the chamber controller. For the RF Test, we may have limited instrumentation and so we need to complete the tests on our DUTs one at a time, thread0, thread1, etc. where the test running on thread1 only executes when thread0 completes. For the final test, Vibration Analysis, we may need all of the DUTs to be measured in parallel to reduce test time. All of this can be configured within TestStand by selecting the synchronization properties.
The largest issue with fully asynchronous parallel testing is that because there is no implicit synchronization around steps, it is more likely that two threads may try to use the same resource. For example, two DUTs steps may try to attain control of an instrument. This conflict is not limited to steps though, it can also appear anywhere in the sequence where two separate operations try to acquire a common resource. To eliminate this issue, when using TestStand, you can place "Locks" on resources from anywhere in the sequence. You can lock a step, so one thread can operate on it, similar in operation to the batch models "Serial" mode, or alternatively you can lock any named resource, such as a common instrument. When this lock is in place, any other thread which tries to operate on the step, or attain the resource, pauses until the previous step completes and releases the resource. Using the locking mechanism makes the best use of your instruments. When you define a lock, your instrument is always busy. When it completes the test on the first DUT, it is immediately refocused on to the next DUT.
Using NI TestStand and Acculogic's TPS team, parallel test systems have become significantly easier to create and maintain. This framework provides a flexible and adaptable testing environment that can be readily modified as requirements change. Together, Acculogic and NI TestStand offer a robust, efficient, and scalable testing solution that reduces the time needed for test setup, execution, and analysis, leading to faster production cycles.