COTS software prevents ATE obsolescence
Nate D'Anna, National Instruments -- Test & Measurement World, 4/1/2006
The notion of using interchangeable parts in manufacturing has existed for centuries, spanning back to the late 1700s when inventors began creating muskets composed of interchangeable parts. Others have since used the principle of interchangeable parts to improve older gun models with upgraded components, even sharing common parts between different gun models.
Fast-forwarding to this century, can you apply the principle of interchangeability to your automated test equipment (ATE)? Can you replace outdated components with newer models, even ones made by different manufacturers?
For many military and aerospace test engineers, the answer is a resounding "no." Too often, companies are still dependent on fixed, proprietary ATE systems that are not flexible enough to meet demands for greater tests and higher performance.
Yet, this need not be the case. In this era of virtual instrumentation, test engineers can use commercial-off-the-shelf (COTS) software tools and modular hardware to create long-lasting ATE systems that can both reuse legacy code and evolve to meet new testing challenges.
Test-management software
 |
| Fig. 1 A test architecture that combines flexible, COTS software with modular hardware helps prevent test system obsolescence. |
The test-executive software should provide interactive module adapters that let you add, configure, and execute TPSs programmed in various programming environments. With this functionality, you can reuse existing code and add modules that support new tests.
Even with new modules in the test system, the test executive should continue to manage TPS sequencing and threading with minimal changes. This approach lets you replace obsolete modules instead of replacing an entire ATE system.
As demands for increased throughput and shorter test times grow, the fixed nature of traditional ATE systems cannot compete with a software-defined approach. With a test executive, you simply configure your test sequence to run multiple TPSs in parallel, greatly increasing performance, while insulating programmers from complicated multithreading models. You can use a similar approach to scale the number of units under test, all without modifying TPS code, and continue to increase the throughput of your existing testers.
 |
| Fig. 2 TPS development environments provide a test platform that promotes backward compatibility. |
Inevitably, as test systems designed to last only a few years move into their second decade of operation, engineers face the likelihood of having to update the hardware. Using a forward-looking software strategy with modular hardware can make this process easier.
Application programming interfaces (APIs), such as Virtual Instrumentation Software Architecture (VISA), provide a common interface for communicating with instruments over various buses, including IEEE 488, Ethernet, and USB. As a result, if you want to replace the IEEE 488 connection to an instrument with an Ethernet connection, you simply need to modify the name of the instrument descriptor.
Interchangeability between instruments is further facilitated with the use of interchangeable virtual instruments (IVI), which define standard instrument classes, such as those for scopes and function generators. If you write the instrument code of a TPS using IVI, you can replace an instrument with an improved model from a different instrument vendor (assuming it is from the same IVI class) without changing a single line of source code. You can also take advantage of modular hardware platforms such as PXI, which let you easily replace instruments with newer models that provide better specifications.
| Author Information |
| Nate D'Anna is a LabWindows/CVI product manager at National Instruments. nate.danna@ni.com. |
