Multihead technique is auseful way to increase the efficiency of functional test inmanufacturing and significantly lower capital equipment costs. The full benefit of multihead testing requires sophisticated multithreaded management.National Instruments TestStand software has this architecture.
Eric Starkloff, National Instruments,Austin, TX, USA
Increasingly, test times are scrutinized as a means to lower costs in high-volume manufacturing. Typically, functional tests cannot keep up with the throughput of a production line, so several testers are required for each line. Because racks of test equipment are expensive and consume factory floor space, this „fanning out“ of testers must be kept to a minimum to keep costs down. Depending on instrumentation utilization, a single rack of test equipment can have multiple fixtures or testing heads to accommodate multiple units under test (UUTs) in parallel. These so-called multihead testers can result in significant improvements in testing efficiency. To maximize instrumentation usage and thuslower capital equipment costs, however, a sophisticated software architecture is required to automate multihead testing. Multithreading is one technology that has emerged as a means to accomplish maximum efficiency while maintaining a relatively straightforward test programming structure. The TestStand, a test management and execution environment, provides a multithreaded architecture that makes the implementation of a multihead tester as simple as possible while maximizing the efficiency of the tester.
Two important parameters that characterize the speed of a production line are pulse rate and cycle time. Pulse rate is defined as the number of UUTs per unit time coming off the production line in need of testing. Because pulse rate is typically defined by the speed of the production line itself, it is often given to a test engineer as a fixed parameter. Cycle time is the duration of time is takes to test and handle a single UUT. If cycle time were the reciprocal of pulse rate, you could test each item just as it comes off the line. But because cycle time is very often greater than the reciprocal of the pulse rate, it is necessary to place several testers in parallel to keep up with the line. Thisrelationship can be stated as a simple equation:
Number of testers = cycle time x pulse rate
To illustrate this, lets look at a simple example. Suppose you have a line producing widgets at the rate of 1 widget/45s. Thus, the lineÔs pulse rate is 1/45 units/s. You design a series of functional tests for this widget and determine that each functional test takes, on average, 30s. In addition, it takes 10s for a robot to place each widget in the test bay before testing. After testing, it takes another 20s to write results to a database and then remove the UUT from the test fixture. To determine how many functional testers you will need to keep up with the production line, calculate:
Number of testers = 60s x 1/45 units/s = 1.3 = 2
Thus, two testers per production line are required. You could simply have the line fan out to two independent testers or you could implement a single multihead tester. A multihead tester is a test stand with fixturing, instrumentation, and software capable of testing two or more UUTs in parallel. Such a tester commonly uses a single computer and can share expensive instruments to lower capital equipment costs. In addition, a multihead tester occupies much less floor or bench space than several independent testers.
The immediate benefit of a multihead tester is that it can reduce or eliminate the handling and reporting time in the systemÔs cycle time. Note that on the dual-head timing diagram, one unit can be put into a test bay while the other unit is being tested. Thus, in the case when a steady stream of products is coming off the production line in need of testing, the cycle time of the dual-head tester is reduced to 30s, from 60s in the single-head case.
Additional significant reduction of testing time can be achieved by implementing intelligent parallel testing between the two test beds. By duplicating installations of lower cost, or more heavily used instruments, you can run actual tests in parallel on each head, resulting in the optimum combination of equipment cost and testing efficiency.
How multithreading works
Implementing a multihead tester however puts more vigorous demands on the software that controls the test system. It must simultaneous track multiple units and record their results while also communicating with handlers and other peripheral devices. A modern software technique used to meet these demands is multithreading. Multithreading is a technology used by modern operating systems to execute multiple routines in parallel within a single application. The application divides a task into multiple subtasks, called threads. The operating system constantly switches execution among threads. Because processors are so fast, this switching happens at a high rate, and the threads appear to run in parallel. A multithreaded program takes advantage of this technology by scheduling actions on multiple threads so that they can be executed in parallel. The advantage for test and measurement applications is that a multithreaded system makes several measurements in parallel to better use hardware from a single computer. Because the computer processing time is small in comparison with bus accesses and hardware I/O, the many threads can be run on a single processor without slowing down the system. In one of the increasingly popular multiprocessor PCs, the operating system automatically divides the executing threads between the processors, resulting in true parallel execution that dramatically increases performance in many situations.
Let’s examine the general case of a production line with N electrical testers at the end of each row. Typically, each tester is identical and operates independently. This means that all instruments and software are duplicated in each tester. Because it is very unlikely that all N multimeters, for example, are always being used at the exacttime, this is a tremendous waste of resources.
One challenge in implementing a multihead tester, however, is in the software. Executing tests in parallel, tracking multiple UUTs, and sharing resources requires more sophisticated testing software than simple sequential testing. Creating test management software to handle these complex issues is a daunting task. The multithreading architecture of National Instruments TestStand, though, provides the user with a powerful, off-the-shelf tool to implement multihead testing software. The engine is a sophisticated sequencer with full multithreading capability. An operator can open multiple TestStand sequences in the environment and execute them in parallel. The sequences run independently; one sequence can be paused, debugged, or terminated without effecting the execution of all other operations.
Sometimes parallel executions will run completely independently; that is, they have no interaction with, or effect on, other simultaneous executions. More often,however, there will be some sort of interaction between the executing threads. Whether it is a shared variable, shared equipment, or certain tests that must be executed at precisely the same time, synchronization techniques must be implemented to schedule threads and manage shared resources. Synchronization techniques include:
• Locking – preventing all other threads from accessing a variable,resource or section ofcode
• Events – objects used to notify other threads that something hasoccurred
• Semaphores – objects used to give access to a shared resource to only a certain number of threads at a time
• Rendezvous – objects used to synchronize the execution of multiple threads at a pre-determined point
TestStand supports the use of all of these techniques within a procedure. For example, you might be testing two-way radios on a dual-head tester. While many initialization and self tests run independently in parallel, there might be certain tests that should not be run on both units at thesame time due to interference, and other tests, like a transmit/receive test, that must be synchronized to happen at exactly the same time on both units. In this case, you would create a TestStand sequence that starts two executions in parallel when the units are placed in the testing heads. On the RF tests, where you must prevent testing at the same time on each head, you would use locking within TestStand. For the transmit/receive test, you would use a semaphore to insure synchronization.
One of the compelling reasons for using a multithreaded test platform is that more efficient instrument usage can be obtained by intelligently sharing instruments. This increase in efficiency can lead to dramatically lower capital equipment costs. To share instruments in a multithreaded application requires resource management in order to ensure that only one thread has access to the instrument at a time. For most instruments, an IVI (intelligent virtual instrument) or VISA-compliant instrument driver exists. These standard drivers include functions for locking and unlocking instrument resources. Thus, these drivers, when used correctly in a multithreaded testing scenario, ensure that multiple threads do not access the same instrument at the same time. Note that an IVI instrument driver automatically caches the state of the instrument, so while you program the instrument with high-level function calls in your program, the instrument driver ensures that no redundant commands are sent to the instrument. Without a state-caching driver, a multithreaded program cannot predict which state the instrument might be in at any given time, and thus must explicitly set all attributes on the instrument to a known state before making a measurement, resulting in some degradation of the testing performance.
Durch stets komplexer werdende ICs (Systeme auf Silizium, sytems-on chip) deutet vieles darauf hin, daß der Funktionstest in der Baugrupenfertigung eine Renaissance erlebt. Doch sind solche Prüfungen relativ langsam, man braucht also in der Linie mehrere Tester, um Taktzeiten halten zu können. Die Redundanz in solchen Konfigurationen läßt sich mit Multihead-Testing in den Griff bekommen.
Vue la complexité sans cesse croissante des CI (systèmes sur silicium, systems-on chip), le test de fonctionnement semble vivre une renaissance dans la fabrication de modules. Mais ces contrôles sont relativement lents et il est donc nécessaire d’équiper la ligne de plusieurs testeurs pour que les cadences soient respectées. La redondance de telles configurations peut être maîtrisée avec le multihead-testing.
In seguito alla complessità dei circuiti integrati (sistemi di silicio, systems-on chip) sempre più in fase evolutiva, molti fattori danno a pensare che il test funzionale nella produzione di gruppi modulari stesse vivendo un rinascimento. Queste verifiche sono tuttavia ancora molto lente, ciò significa che nella linea si necessita di un numero maggiore di tester, al fine di poter rilevare i periodi ciclici. La ridondanza in simili configurazioni può essere dominata nel migliore dei modi con il procedimento Multiheed-Testing.