Home Shop PXI Systems Don't Let Obsolescence Cause Your Test System to Flatline

Don't Let Obsolescence Cause Your Test System to Flatline

Updated Apr 5, 2023

Overview

If you are testing a consumer device that lasts in the market for one year and are replacing test systems almost as often, then this article isn’t for you. On the other hand, if you are testing devices and components that will last a decade or more and having to plan technology updates and obsolescence events for test systems that might live even longer, then here are three key methods to plan ahead and protect your system from incurring extreme effort and cost in the future.

 

Contents

Build a Layered Software Architecture With HALs and MALs

Don’t get locked into an inflexible test program by building a monolithic architecture; instead plan ahead by building layers that perform separate test operations.

In a monolithic architecture the UUT test program includes code that manages test flow control, test execution, UUT stimulus, measurement analysis, limit checking, result logging, operator user interface, and instrument resource scheduling. This single source of functionality means that any new test requirements that arise due to an obsolescence event, require the entire test system to be revalidated.

 

Figure 1. A single code base to handle all test program tasks seems like a good way to develop until it becomes inflated and difficult to change or repair. Using smaller, modular code bases for different tasks keeps a test system more extensible.

 

Instead, create a modular software architecture that has separate code bases for all critical test system functions. Test management software like TestStand handles common test program tasks such as test flow control, test execution, result logging, limit checking, operator user interfaces, and instrument resource scheduling. Test code should be responsible for tasks specific to the UUT like stimulus, measurement, and analysis functionality.

 

 

HALs help you to develop high-level code that calls a function that returns a value from an instrument without knowledge of the specific instrument and device configuration. The most common HALs are provided by instrument vendors and industry standards such as IVI. Building these layers into your code gives you the flexibility to change instruments without altering measurement analysis code, the tester’s user interface, or the overall test structure.

 

Figure 2. A MAL and HAL empower test engineers to choose the test result needed and allow the test system architect to maintain instrument driver and hardware operability.

 

A HAL alone does not protect a system from changes in hardware or instrument drivers. Some instruments have an overlap of functionality and could be used to complete tests in place of a busy or malfunctioning device. A good example of this is taking current measurements with a digital multimeter (DMM). A source measure unit (SMU) could be used even more effectively to take that measurement in many cases.

MALs allow a user to define a measurement or test type and gives the test system the ability to choose the correct and available resource to deliver that result. Test systems built with MALs are even more flexible and resistant to changes in instrument drivers and hardware.

Want to learn about implementing a HAL or MAL in LabVIEW object-oriented programming (OOP)? Watch a free online training video now.

 

Back to top

Use Flexible, Modular, Software-Defined Instruments

The best instruments for building long-lived test systems are flexible enough to perform all of the necessary measurements and easily replaced in software and physically in the test system.

Instruments with software-configured measurements have the flexibility to take the right measurement to get the results needed. Many times these instruments have extensive code-compatibility with other instruments using industry-standard or good vendor-defined APIs.

A test system designed around a modular instrumentation hardware standard like PXI is much easier to upgrade and service over time. Replacing a traditional instrument means accounting for size, heat generation, power consumption, and a number of other factors. Upgrading or replacing a modular instrument is as easy as removing the old instrument from its slot in the carrier and replacing it with the new one.

 

Figure 3. NI’s instruments with programmable FPGAs help you to create custom measurement features like triggers and signal processing as well as interoperative device firmware.

 

Instruments with open FPGAs add another level of instrument compatibility by giving test engineers the ability to design the firmware of an instrument and reuse that firmware on other, compatible instruments as necessary. This type of customization isn’t always necessary, but can help maintain the existence of important features that could go obsolete over time.

See how instruments with programmable FPGAs give you the ability to design instrument firmware with features like custom trigger modes.

 

Back to top

Know the Life-Cycle Status of Your Hardware

The best long-term test systems are built on platforms and have a constantly updated sustainment plan informed with all essential information about the life cycles of hardware components in the system.

Getting life-cycle information requires establishing a cooperative relationship and good communication with suppliers and the diligence of suppliers creating plans for the future. Instrument vendors should empower you to plan for technology evolution in your system and even share roadmap information where possible. Instrument vendors should also provide services ranging from upfront consulting on product selection to long-term extended service agreements to meet your specific needs.

 

Figure 4. Hardware obsolescence events can be handled using a number of methods that each have benefits and costs. Some vendors are making the integration of new hardware and technology easier with backward-compatible software.

 

With this kind of life-cycle information, you can consolidate technology updates and reviews that include extensive information empowering you to make the right decisions.

Learn more about NI’s vendor-provided life-cycle information and services.

 

Back to top

Next Steps

  • Get the details on best practices for designing long-living test systems.
  • Explore the PXI modular platform for test system instrumentation.
  • See why TestStand is the market-leading software development tool for production automated test system management.
Back to top