Designing and Maintaining a Test System for Longevity

Becoming a technology laggard in the 21st century is far from inconceivable. As human dependence on gadgets grows, the demand for developing new technology intensifies. Cell phones are prime examples of products that are continually evolving. The typical cell phone begins production, goes into distribution, and becomes obsolete all in less than three years. Such rapid technological advances mandate that test systems built to examine products with fast life cycles be expandable to sustain product growth over the long haul. These systems must not only be modular and flexible to support copious tests that may vary between product models, but they also must be scalable to accommodate a larger number of test points. Most importantly they must be cost-effective and easy to use so as to reduce development time.

For a single test system to have all of the above listed features would involve the use of scalable software coupled with modular and expandable hardware. The goal of this document is to list software, hardware, and maintenance/support considerations that can prepare engineers to design quality test system architectures with extensive life spans.

The software component of a test system is used to deploy the hardware and display processed data to the end user. The ideal software package should minimize the effort required when developing and expanding the test program and, thus, streamline the productivity of software engineers. This section lists the factors to consider when choosing software tools for designing long-term test system architectures.

• Modular Software Framework Optimized for Scalability
• Code Reuse Features
• Supports Platform Independence

Test systems built for longevity usually require modifications during their life spans. To make the process of incorporating these changes into the test program less time-consuming, the software must be scalable. Examples include easy-to-use application programming interfaces (APIs) that minimize the need to learn hardware caveats and the abundance of example code that serves as a starting point for any application. It must also minimize the effort required to perform new analysis on data acquired from the hardware by providing a host of precoded analysis functions that perform complex mathematical processing.

Test systems often need to be expanded either to accommodate more test points that may be required for testing newer models of a device under test (DUT) or to perform new tests on an existing DUT. Thus, software used to write test applications must not only be able to support hardware expansion but it must also simplify the process of modifying existing test code by maximizing code reuse. Some software tools do this by providing interactive configuration utilities that convert user input into data that is then used by the test code. By taking advantage of such utilities, users can expand the test program by making changes to the configuration file rather than to the actual code, thus reusing existing code. Another way that software can maximize code reuse when system hardware changes occur is to support drivers that use a standard communication protocol to program multiple instruments with the same API. Interchangeable Virtual Instruments, or IVI, are a prime example of such drivers, as shown in figure 1. IVI drivers are sophisticated instrument drivers that feature increased performance and flexibility for intricate test applications that require interchangeability, state caching, or simulation of instruments. These drivers minimize the need for hardware engineers to learn new protocols or hardware commands that may vary among instruments from different vendors.

^{Figure 1: An IVI driver architecture maximizes code reuse and works with multiple hardware platforms.}

Lastly, systems built to sustain long-term technological advances must be flexible and use application development environments (ADEs) that can withstand structural changes by working with multiple hardware and software platforms. If the ADE does not support these multiple platforms, programmers need to use different ADEs for different projects and spend time porting existing intellectual property from one platform to the other. Consider an older application built to work on Windows 98 that needs to be transported over to a newer PC that runs Windows XP. If the ADE used to develop the code did not support Windows XP, the test program would have to be completely reconstructed. Similarly, imagine that your application needs change and you must add a new measurement device. If your development software does not support this new hardware, then you may have to substantially change the application. Both scenarios would exponentially increase development time and significantly affect the efficiency of the test engineer. Therefore, a software package well-suited for designing test system architectures for longevity must support multiple vendor hardware platforms and numerous OSs. Moreover, it must be built on an adaptable framework that simplifies the process of adding support for new hardware and OSs when needed. Software with these features helps minimize the time needed to modify existing test code when new hardware or tests are introduced in the system, thus increasing application longevity.

Consider a DUT that is a product model of a gadget that is constantly evolving – for example, the Apple iPod. Older versions of this device such as the iPod mini (now obsolete) were audio-only devices. Newer iPods can play sound as well as video. An evaluation of past trends and the wide adoption of the iPod show that it is possible that future versions of the device will incorporate additional features. Testing complex and evolving devices such as the iPod requires a flexible hardware platform that is constantly growing. This section lists the factors to consider when choosing hardware platform for designing long-term test system architectures.

• Open Industry Standard
• Modular and Flexible for Easy Expansion
• Ability to Meet Various Test Needs

With technology evolving, test needs are bound to become more complex. Therefore, it is crucial that the hardware platform chosen to build the test system is continually growing as well. Such a platform eliminates the need to completely redesign a test system architecture when its maximum capacity is reached. Open industry platforms, such as PXI, VXI, and GPIB, are usually good examples of this type of hardware. This type of platform reap the benefits of multivendor adoption, which include constant growth and innovation. Increased channel-count, voltage, current, speed, and accuracy specifications are just a few areas in which vendors that manufacture open-standard hardware compete with each other for industry recognition. This competition fosters healthy platform growth and a constant supply of new products to meet the needs of advanced test systems.

Open standards that are modular further reduce system costs by maximizing component reuse. Their flexibility eliminates complexities when system expansion is needed. Because test systems built for longevity are often expanded to incorporate more I/O points during their life spans either to test new DUTs or to add testing features to existing DUTs, a flexible hardware foundation is crucial. Hardware chosen in test systems that need to last several years must have the ability to perform a vast number of tests. To do so, it must have a large portfolio of products that can perform tests on analog, digital, and RF signals at various levels with accuracy and speed. With the iPod example, future versions of the device might need a test system with expanded channel count and the ability to perform video, audio, and maybe even RF (in the case newer iPods that play radio stations). Open-standard platforms, because of their vast product offering and continual growth, are more likely to fulfill these requirements.

Combining the right complementary hardware and software tools can facilitate the design of long-term test system architectures. However, even the right tools are rendered useless if they are not supported by their manufacturers. Systems that have longer life spans need to be updated and calibrated for accuracy. Furthermore, these systems need software updates to keep up with changing software requirements such as updating the OS of the application from a previous Windows version. Lastly, hardware components in systems built for longevity have a higher likelihood of needing repair. These factors mandate that products used in long-term test systems come from manufacturers that provide support services such as:

• Technical support (phone and Web)
• Calibration services
• Software subscriptions
• Repair
• Warranties

Engineers should preferably choose hardware and software that have longer life spans than the system itself. If this is not possible, they must ensure that these products are manufactured by vendors who have a strong track record for providing drop-in replacements and support for obsolete products. Without vendor support, technical issues and unforeseeable problems in the system can be hard to troubleshoot. This can sometimes cause unwanted delays and, in more extreme circumstances, require the construction of an entirely new system.

National Instruments is committed to providing products and services that engineers can use to build test systems for the long term. The recommended solution is a five layer system architecture that was introduced in the executive summary of this guide. This section will highlight the main products and services that ensure support over the long-term. From a software perspective, the NI LabVIEW platform forms the core of all NI software. As a graphical programming language, NI LabVIEW is based on three basic steps that can be used to construct any test program – acquire, analyze, and present.

^{Figure 2: There are three steps to programming in LabVIEW.}

For acquisition, LabVIEW has APIs, as shown in figure 2, for programming various NI hardware devices such as DMMs, RF instruments, digitizers, programmable power supplies, and multifunction data acquisition devices. Because these APIs are the result of cohesive efforts by NI hardware and software R&D engineers, they follow the same programming sequence. This consistency makes programming various instruments in LabVIEW menial and eliminates the need for programmers to learn the nuances of each instrument. Most importantly, it minimizes development time. To simplify the acquisition process even more, LabVIEW uses configuration wizards and follows the dataflow paradigm, making it simple and intuitive for first-time users to write test code.

In addition to acquisition, the LabVIEW platform offers hundreds of built-in analysis functions that cover different areas and methods for extracting information from acquired data. Programmers can use these functions as is or modify, customize, and extend them to suit a particular need. These functions are categorized in the following seven groups: measurement, signal processing, mathematics, image processing, control, simulation, and application areas. View the LabVIEW for Measurement and Analysis tutorial for more information on analysis tools in LabVIEW.

LabVIEW also has a vast number of abstraction features such as charts, graphs, knobs, and the ability to export data to data management software such as Microsoft Excel or NI DIAdem, which help present analyzed data to the user in a clear fashion. Data presentation also can be done between locations by making use of the LabVIEW ability to publish data to the Web or log information to a database. Cohesively, these features make LabVIEW scalable and ideal for building long-term test system architectures.

For a test system to function, its software and hardware need to work in a congruent fashion by complementing each other. It is just as important to select the right hardware platform as it is to pick a powerful software tool when designing a test system for longevity. Using a flexible open hardware platform, such as PXI, minimizes the need for test system replacement as product life cycles end and technological advances are made. This increases test system longevity.

PXI is an open-standard platform used by various test and measurement industry leaders who are all members of the PXI Systems Alliance. Currently, the more than 70 companies worldwide that are PXI Systems Alliance members share a common commitment to providing an open platform equipped for a variety of applications, from machine control to automated test. Growth of PXI modules has been rapid since the adoption of the PXI standard in 1998, and today more than 1,200 PXI products are available. In addition to a vast product offering, PXI is also expected to continually grow for the foreseeable future. These PXI characteristics make it suitable for use in long-term test systems.

Its modular nature also makes PXI suitable for building test systems for longevity, as shown in figure 5. Expanding a PXI system to incorporate more I/O points or new testing capabilities is as easy as adding one of the more than 1,200 available modules to an empty slot in a PXI chassis, which is the outer frame of the system. Because all instruments are powered by the chassis, components such as the chassis fan and the power supply are reused to the maximum.

Other modular platforms made by National Instruments include NI CompactDAQ, a low-cost alternative to PXI, and NI CompactRIO, an FPGA-based platform designed for high-speed control and deterministic test applications, as shown in figure 6. By designing modular system hardware that maximizes code reuse while catering to a vast number of applications, National Instruments provides test engineers with a selection of hardware platforms appropriate for designing long-term test systems.

NI also makes every effort to support obsolete products by providing technical assistance via the Web in the form of knowledgebases, tutorials and example code, and discussion forums and by offering drop-in replacements for hardware products that go “end of life.” Using these services, NI hardware and software can be maintained and sustained over the long term.

You should consider software and hardware platforms that are designed to support long-term maintenance and upgrades. While hardware and software products can help build an efficient test system for longevity, it is the availability of product support from the manufacturer that determines whether it will be maintainable. In the universe of technology, what is advanced today may be archaic tomorrow – there is no avoiding that fact. With proper planning, it is possible for the test system to avoid a similar fate.

National Instruments, a leader in automated test, is committed to providing the hardware and software products engineers need to create these next generation test systems.

Software:

• NI TestStand Test Management Framework
• LabVIEW Graphical Programming Environment

Hardware:

• Modular Instruments (Oscilloscopes, Multimeters, RF, Switching, and more)
• Multi-function Data Acquisition
• PXI System Components (Chassis and Controllers)
• Instrument Control (GPIB, USB, and LAN)