Designing and Maintaining a Test System for Longevity

Overview

This white paper provides strategies for maintaining a test system for longevity.

Contents

Introduction

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.

Software Considerations


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.


To achieve interchangeability, the IVI Foundation has defined specifications for the following eight instrument classes: digital multimeter (DMM), oscilloscope, arbitrary waveform/function generator, DC power supply, switch, power meter, spectrum analyzer, and RF signal generator. For the purpose of illustrating the advantages of IVI, consider a DMM/switch system that is being expanded. Because of higher throughput demands, an additional DMM might be needed. However, because of cost constraints, a cheaper model of the instrument is chosen from a different vendor. If the test program for the system were written using IVI drivers, the code to deploy the first DMM could be reused to deploy the second one as well. For more information on IVI, visit the IVI page.

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.

Hardware Considerations


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.

Maintenance and Support Considerations


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.

NI Solution for Building and Maintaining Test Systems for Longevity

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.

 

Figure 3: LabVIEW is an intuitive graphical programming language that provides tools such as charts, graphs, and buttons to abstract information for the user.


LabVIEW also comes with built-in features and add-on modules and utilities to help reuse existing code. These features include interactive configuration wizards such as Measurement & Automation Explorer and NI Switch Executive, which convert user input into data that is fed into LabVIEW test code, as shown in figure 4. Using such graphical configuration wizards, programmers can add hardware to programs by making changes to the configuration file rather than to the test program. This maximizes code reuse and increases development efficiency. In addition to configuration tools, the LabVIEW platform offers users a host of IVI class drivers to help maximize code reuse in the test program. For more information on IVI, visit the IVI page.

 

Figure 4. Engineers can use NI Switch Executive to configure and deploy a 9,216-crosspoint switch matrix within minutes.


The last requirement that software packages need to meet is platform independence. Complex test systems sometimes require precision instruments. When an NI solution for such instruments does not exist, programmers can make use of more than 5,000 FREE instrument drivers to program instruments from numerous vendors including Agilent, Fluke, and Keithley. Learn more on the Instrument Driver Network page. In this way, programmers can use the LabVIEW ADE to program instruments from multiple vendors, making it independent of the hardware platform. LabVIEW also supports multiple OSs and can be deployed on Windows, Mac OS, Linux®, real-time OSs such as PharLap, and even FPGA. The flexibility of LabVIEW is one of its biggest assets. Using traditional text-based languages programmed in Windows, on an FPGA, and on an embedded processor would require engineers to learn three completely separate languages (for example, C, VHDL, and TI Code Composer Studio). Using LabVIEW, engineers can deploy applications on all three targets in the same environment, maximizing efficiency and minimizing time spent learning new tools.

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, as shown in figure 5. These PXI characteristics make it suitable for use in long-term test systems.  


Figure 5. The PXI platform has enjoyed exponential growth over the past eight years and is forecasted to continue growing.


Its modular nature also makes PXI suitable for building test systems for longevity, as shown in figure 6. 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.

 


Figure 6. The modular PXI platform makes system expansion easy.


In addition to being an open standard and modular in nature, PXI has a wide span that addresses the needs of various applications from vision testing to high voltage and current testing (high-power applications) to even RF test. PXI modules can perform these tests with accuracies of up to 7½ digits (26 bits) and rates up to 6.6 GS/s. PXI instruments are also suited for mixed-signal tests that involve both analog and digital signals. Some modules also come with built-in signal conditioning for the measurement of sensors such as thermocouples, RTDs, load cells, and strain gages. The PXI platform also has FPGA modules and real-time capability, making it suitable for test applications that need determinism. To learn more about its capabilities and offerings, visit the PXI page.

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 7. 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.


Figure 7. Other modular platforms manufactured by NI include NI CompactDAQ and CompactRIO.


National Instruments has a commitment to providing an array of quality hardware and software products that make designing test system architectures for longevity as elementary as possible, as shown in figure 8. NI makes every effort to support these products by providing calibration services; technical support via phone, e-mail, and Web; and numerous repair and warranty options.

NI also makes every effort to support obsolete products by providing technical assistance via the Web in the form of knowledgebasestutorials 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.


Figure 8. As NI releases new products, it continues to support older ones.

Conclusion

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.

Relevant NI Products and Whitepapers


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:

Hardware:

Test System Development Resource Library

National Instruments has developed an extensive collection of technical guides to assist you with all elements of your test system design. The content for these guides is based on best practices shared by industry-leading test engineering teams that participate in NI customer advisory boards and the expertise of the NI test engineering and product research and development teams. Ultimately, these resources teach you test engineering best practices in a practical and reusable manner. Download guides from the Test System Development Resource Library.