Three ways to solve the problem of obsolete ATE

Test systems used in aerospace and defence applications typically have a lifespan of 25 years or more - far longer than the lifespans of the individual measurement instruments that comprise the system. Replacing obsolete instruments can have major negative consequences for the deployed test program set (TPS) and for the maintenance, calibration and repair costs of automated test equipment (ATE).

By employing instrumentation with a sophisticated emulation strategy, however, the new test instruments can be successfully integrated using a less expensive, more efficient migration path. 

Solving the problem

Between 1980 and 1992, the US Department of Defense spent over $50 billion on ATS procurement. During this period, the standard practice was to develop a unique ATS or ATE to support a single military system, which resulted in a proliferation of hard-to-maintain test systems.

Solving the problem of test equipment obsolescence is both difficult and necessary because the cost of system ownership is greatly influenced by ATE calibration and repair costs and by the current maintenance procedure for TPSs. There is also an increasing risk of replacement parts becoming unavailable and of calibration and repair capabilities eroding during the system’s lifetime once the instrument is no longer supported by the vendor.

Emulating obsolete devices

Test program sets used in ATE systems are generally certified, which makes it very time-consuming and costly to modify and reapprove them when an obsolete instrument is replaced.

Replacement also triggers software modifications - and the cost of a TPS rewrite almost always exceeds the cost of instrument replacement. It is therefore cost effective to manage instrument replacements without changing the existing TPSs.

An attractive migration strategy is to deploy new measuring instruments that emulate the discontinued instruments. This approach saves time and is cost-effective but not trivial.

The requirements for the instruments are determined by the test programs themselves and by the electrical and functional features of the instruments to be emulated.

Figure 1: The SMA100A can be controlled by commands other than the built-in native SCPI commands.

Different strategies

There are three basic approaches to solving the obsolescence problem: ATEs can be maintained, modernised or upgraded. The appropriate choice depends on remaining ATE system life and on cost.

Maintaining an existing ATE by repairing its instrumentation has lower costs and is relatively simple, but is limited to the number of years the legacy instruments are available.  Benefits are zero or few changes to hardware and software and minimal capital expense. Problems are the limited time span, higher downtime and the increased risk when the product is no longer supported.

Modernising or replacing the entire ATE solves the code compatibility issue but also has much higher costs and usually can be done only during major program updates or extensions.

Advantages include greater reliability, faster tests and extended life. On the other hand, this approach requires major changes to hardware and TPS that lead to higher complexity, compatibility issues, higher risk and high costs.

Upgrading the ATE with modern instruments is a middle way that has the potential to create modern systems at reasonable cost. It requires, however, that the line replaceable units (LRU) or units under test (UUT) give the same response when stimulated with the replacement instrument as they did with the legacy instrument. In other words, the replacement has to be done with code-compatible instruments.

Achieving code compatibility

Replacing legacy instruments with new instruments that emulate them exactly usually requires the same hardware interface (GPIB) used by the existing test system. It also requires adopting the existing command language (eg, for frequency and measurement range setting, dynamic range setting and noise-level setting for the replacement instruments).

Fortunately, the SCPI (Standard Commands for Programmable Instruments) standard has significantly reduced the problem of interchangeability. Footprint in most cases is not a problem because modern instruments tend to be smaller in size and have lower power consumption.

Faster testing (increased throughput, higher yield) may also be possible because the replacement instruments deliver higher accuracy and speed and this can lead to higher margins for the DUTs. Other benefits include minimal hardware and software changes, greater reliability and reduced cost of ownership.

Since the late 1990s, remote control of instrumentation has been based on the common SCPI standard. Before that, legacy instruments used vendor-specific command sets that had their own syntax and semantics.

To make these instruments compatible with earlier generations at a minimum requires switching from the SCPI parser to a parser for the legacy commands that understands the old syntax. But just translating the legacy commands into SCPI is not enough. The right emulation mode has to be activated first as well as the selection of the emulated instrument model. (Although most of the legacy instruments share a common set of remote commands, each model may respond to the commands quite differently.)

Rohde & Schwarz has acquired knowledge and experience in understanding the requirements and challenges of emulating a variety of complex instruments. In order to achieve behavioural compatibility, for example, the emulation capabilities of modern spectrum analysers must appropriately handle different mixer levels, analog vs digital resolution bandwidth filters, and swept frequency spans vs digital FFTs.

The company’s Legacy Pro concept has been developed for precise emulation. It enables an instrument not only to understand the legacy commands for correct implementations but also to generate responses - such as measurement results and query results - understandable to the existing TPS.

Getting into emulation mode

Activating emulation mode includes selecting the particular model of instrument to be emulated. Instruments from an earlier family might have a common set of legacy commands but they can show considerable differences in many areas.

It is also very important for the emulation to function in both directions. Besides being able to understand and be capable of processing incoming commands, the new instruments must also deliver responses such as measurement or query results to the control program that are compatible with the emulated instrument.

In addition, activation of emulation mode enables proper adaptation to the different preset settings of the instruments to be emulated (eg, for a spectrum analyser: span, start and stop frequency, number of trace points, reference level and bandwidth coupling).

Activation of emulation mode (or native mode) can also be handled automatically by means of a control command. This makes it possible for new control programs to take advantage of the features provided by instruments in addition to their emulation capabilities.

Figure 2: Emulation mode: Selection of legacy signal analysers to be emulated by the FSV.

ID string emulation and response formats

To address different members of the same instrument family, simply editing the ID string is often sufficient. For a valid ID string emulation, the response to a query for an instrument ID must match the original. ID strings should also be editable manually. In addition, preset settings need to be adjusted to match the legacy instrument.

Properly formatted instrument responses to queries by the control program are essential for proper emulation of previous instruments, along with identical formatting of all parameters (integer, float, ASCII strings) and an identical number of characters.

When querying trace data from a spectrum analyser, it is particularly important for the different query formats of previous instruments to be implemented to result in correct emulation. For example, legacy analysers provide different formats for reading out trace data.

Figure 3: Emulation mode: Sample selection of a legacy signal generator to be emulated by the SMA100A.

Service requests and status reporting

Service requests are messages the instrument sends to the controller when specific conditions or events occur that require a response by the controller. An example would be a message indicating that the analyser has completed a sweep. The controller analyses the different events and status messages using status byte queries.

Service requests and status reporting present a tricky emulation problem. Although they are defined in the IEEE488.2 standard, legacy instruments implemented this functionality only partially and with different behaviours.

Since the requirement is an identical response to service request, not only the status bits of the legacy instrument must be emulated, the behaviour of the status bit combinations generated by the legacy instrument has to be emulated too. The responses of the status reporting (service requests) must be simulated as precisely as possible, including the response times and the related assignment of the status registers.

Modifications may be needed

Sometimes a problem arises due to the different functional feature sets of the legacy instrument and the new instrument. The challenge is to replace a legacy instrument eg, HP8340B with a new instrument eg, the SMB100A, when the feature set of the legacy instrument is not a true subset of the new instrument. Normally, an emulation would implement the overlapping functions, but not those functions available in the newer instrument. This can lead to faults. The reason is that very often during the initialisation of the application the legacy instrument calls for a function, which is not available in the new instrument and which is never needed during the rest of the application.

The following example illustrates this problem: The HP8340B, for example, sends the command “PD0” to disable the pulse modulation in an application where no pulse modulation is needed. If the legacy instrument is replaced by an SMB100A without pulse modulation option, this command leads to an error message and possibly to a malfunction of the application.

One solution is to implement the unavailable functions as ‘dummies’ for the emulation. This means that set-up commands will be absorbed and polling commands will be answered with default values.

Hardware and timing issues

In today’s instruments, signal processing is fully digital. This means that the analog design of legacy instruments must be carefully taken into account, particularly with respect to timing, filters and level aspect. Reference level differences between modern and legacy spectrum analysers, for example, can be adjusted with internal mixer levels. Emulation with digital filters must fit the shape factor of the analog filters in legacy instruments.

Modern instruments such as analysers, signal generators or power meters are much faster than legacy instruments. In most cases, this is not an issue and even leads to better throughput.

Figure 4: Power meters like the NRP2 are often used in automated test applications.

On the other hand, calibration and self-alignment may take much longer in modern instruments because it takes a larger number of correction steps to achieve higher accuracy. In this case, the solution is to reduce alignment to only a part of the procedure in emulation mode.  Another problem on command execution may occur if test programs are not properly synchronised.

Many ATEs in use today are facing obsolescence problems in the short or mid-range term. Since modern instruments can now emulate legacy instruments and achieve code compatibility in many cases without modifications to the TPSs, migrating to the new generation of instrumentation makes it a strategy worth considering to keep system readiness at the highest level.

Backward compatibility requires both command compatibility and true functional/behavioural compatibility. The advanced spectrum analysers, network analysers, signal generators, power meters and audio analysers provide built-in emulation to ensure the highest possible code compatibility.

The Legacy Pro concept makes it feasible to use the migration approach in test systems if desired and replace obsolete measuring instruments. In many applications, it is possible to continue using existing control programs without any modifications.