Designing automatic test systems for extended duty

Defense organizations such as the US Department of Defense (DoD) operate under perpetual pressure to reduce costs while simultaneously preserving essential defense operations and adding capabilities to confront new threats. One approach is to leverage the designs of prior investments to extend system platform lifetimes with increasing capability. Platforms such as the AAV-7A1, B-52, F-15, and MA Abrams are examples of long-lived upgradeable platforms that continue to serve many decades after their original designs.

Although extending the service life of military systems helps stretch our defense budget, it also exacerbates the challenges already faced by the maintenance organizations and automatic test systems (ATSs) providers who sustain the weapons systems programs. Two particular challenges are:

• Handling the mismatch between lifecycles of the equipment to be tested and the lifespan of the equipment performing the test (see figure 1)
• Sustaining test of a high mix of electronic devices spanning multiple generations of electronic technologies

Fortunately, standards and platform initiatives from DoD organizations and their industry partners give ATS designers and integrators the means of developing solutions for these challenges. Designing systems with modular instrumentation, software-defined instruments, hardware abstraction layers, standards defining common control and information exchange syntax, and high-level test management software tools yields solutions now and also lays the foundation for incremental evolution of these same systems to meet the future demands.

Addressing the lifecycle mismatch challenge
The mismatch between the lifecycles of the units under test (UUTs) and the lifespan of the automatic test equipment (ATE) complicates the task of ATS providers and system maintenance personnel (see figure 1). Because test equipment technology typically evolves at a more rapid pace than the cycle of technology insertions, individual pieces of ATE often become obsolete while defense maintainers still have high demand for them. The cost of mitigating such an obsolescence event depends on how well the ATS system was architected to enable life extensions and capability upgrades.

Designing an ATS with an architecture that incorporates a broadly supported modular instrumentation hardware platform such as PCI extensions for instrumentation (PXI) is one key method for minimizing the cost of solving obsolescence problems.¹ The breadth of industry support for the PXI platform raises the probability of finding a suitable, low-cost replacement instrument. In addition, it increases the possibility of having competitive replacement options. Also, the modular form factor typically minimizes the amount of hardware to be replaced since common resources such as computing platforms, power supplies, cooling components, and other support infrastructure elements are not integral parts of each instrument as is the case with traditional box instruments.

Replacing instrumentation hardware with a suitable replacement is just one aspect of the mitigation process. The objective of test applications within the defense industry is to maintain the ability to test existing devices for much longer period of time compared to commercial production test. Another requirement is therefore the ability of the replacement hardware to perform the existing verified and accepted tests. Existing tests rely not only on the instrument hardware but also on the test program set (TPS) unique to each UUT. Many TPSs may make use of a single test asset being replaced. The development and integration the documentation, software, and interface components that compose each TPS represent a large prior financial investment that a support organization must continue to leverage in order to stretch its budgets as much as possible.

Since redevelopment of these TPSs is costly, ATS systems designed with an abstraction layer between the TPS and the test station hardware assets offer a significant advantage in reducing the expense of obsolescence events. A hardware abstraction layer, sometimes referred to as a software wrapper or simply a wrapper, makes it possible to develop tests with generic commands for controlling test assets instead of using vendor unique syntax. Separating the commanding functionality from unique syntax protects the TPS investment when an obsolescence or upgrade event occurs.

An example of hardware abstraction is using common function calls for instrument classes such as those defined by the interchangeable virtual instruments (IVI) specification.² IVI drivers abstract the generic instrument functionality from the unique hardware implementation, replacing unique manufacturer calling syntax with common instrument command syntax (see table 1).