If you are testing devices and components that will last a decade or more, and you have 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.

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 unit under test (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.

Instead, create a modular software architecture that has separate code bases for all critical test system functions. Test management software 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.

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.

Perhaps the most significant software technique to protect a test system against inevitable hardware obsolescence events is using hardware abstraction layers (HALs) and measurement abstraction layers (MALs).

HALs help you 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.

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

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

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 field-programmable gate arrays (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.

Know the Lifecycle 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 lifecycles of hardware components in the system.

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

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 lifecycle information, you can consolidate technology updates and reviews that include extensive information, empowering you to make the right decisions.

This article was written by Ben Robinson, Product Marketing Manager, Modular Instruments, at National Instruments, Austin, TX For more information, Click Here .