Death of a test box
Jamie Lunn and Keith Randall explain how obsolescence in test equipment can now be overcome.
Thanks in part to program extensions, it is becoming more common for projects in industries such as aerospace and defence to span several decades from initial development to production and deployment. In most cases, in-life support will be required throughout this period, which may or may not include mid-life upgrades to both hardware and software.
Something that can be easily overlooked is the test equipment required to keep a particular system in perfect working order. With COTS test equipment now commonly used, an instrument may pass through several generations during the course of a program’s lifecycle. When instrument models are replaced, new versions are not necessarily compatible with previous versions, either in terms of functionality or remote control commands. This can pose problems when equipment selected at the design stage is built into an automated test system and becomes obsolete during the in-life support phase.
Crucially, the syntax of the commands used to control an instrument tend to be generic to the manufacturer, so although the same hardware control interface is being used (GPIB), the commands differ from manufacturer to manufacturer and sometimes, model to model. This situation was partly rectified with the introduction of the SCPI standard, which manufacturers have begun to adopt in the last few years. This has standardised basic commands, such as telling an instrument to go to a certain frequency or marker, but will not have been implemented in instruments developed more than ten years ago.
Other common occurrences include an older project being written in a programming language that is no longer supported – perhaps the incumbent software team no longer retains the knowledge of that language, or indeed, there is no budget to provide a software resource. It can be that the software contains secure information, so easy access to the source code is not available. Also, any software sequence has to go through a period of validation to verify and prove the code, which can be a costly procedure. All of these factors dissuade from changing the original source code to work with a newer instrument.
A solution to these problems can be found in instruments that can emulate older models, whether from the same manufacturer or a competitor. Ideally what is needed is an instrument that is completely code compatible with the original instrument and offers exactly the same functionality; a drop-in replacement. However, the reality is that emulation is rarely 100% compatible, simply because many software engineers write their code in slightly different ways. In addition, successful emulation relies upon achieving accurate timing compatibility. Special care needs to be taken with respect to commands that directly or indirectly affect the synchronization signals, such as those at the instruments rear or front panel.
From a test equipment manufacturer’s perspective, the process of emulating an obsolete instrument with complete confidence is a very iterative one. Initially a question of implementing all the documented commands and interpreting them to perform the equivalent function on the new instrument, it is then a question of trying it for real on customer’s equipment. Invariably, documented commands have errors or bugs, or there’s variation in how the customer has implemented code, so in some cases, onsite support is vital.
One example of the way that Rohde & Schwarz supports clients to ensure 100% emulation capability is its co-operation with BAE’s Insyte team, which is supporting the Royal Navy’s 966 radar program. With the 966 expected to remain in service until 2016, BAE and Rohde & Schwarz worked closely together to investigate a cost-effective plug and play replacement for the now obsolete HP8722 network analyser in the radar module’s repair/realignment chain. On-site support was provided at various BAE locations in order to log all remote control commands to the native instrument. These were then sent to Rohde & Schwarz’ software development team to map to the new instrument, the ZVA40 network analyser. At this point, risk assessment testing was carried out to prove complete emulation capability, in terms of the existing software and measurement requirements – a far less costly option for the Royal Navy than rewriting the entire system’s software.
Rohde & Schwarz can provide complete emulation capability for more than 60 obsolete test models, including the HP8753 and HP8510 network analysers and the HP8566 spectrum analyser. Notably, Rohde & Schwarz’ FSP30 is also being used on the production test system for the 996 radar system to emulate HP8566 code.
For managers of new long-life programs, the good news is that the introduction of SCPI for the native command language means that there is far less risk of encountering the same degree of emulation challenge for test equipment in years to come. However, SCPI compatibility is just the start: full emulation is a step beyond, giving the test system engineer far more confidence when replacing obsolete instrumentation. Emulation offers the end-user complete interoperability at both the hardware and system software level.
