Reading time ( words)
Test program set (TPS) migration solutions address the problem of legacy automated test equipment (ATE) systems that support validation of military/aerospace systems experiencing end of life (EOL) issues. Robert Peet, SEICA, will review a cross section of ATE systems from both a hardware and software perspective, with specific emphasis on the challenges and solutions for test program sets using LASAR™ simulation. Migrating existing TPS from legacy systems* to current technology can be done at considerably reduced time and cost with modern TPS software migration tools. These allow for easy conversion and migration of functional test (FT) programs, with minimal debug. By retaining features such as guided probe, fault dictionary, and many others, test programs developed as far back as the 1970s are easily ported to state-of-the-art testers without losing functionality. Legacy programs can also be enhanced (post-migration) with new software tools. Modern migration tools, combined with hardware advances, can improve test coverage and diagnostic capabilities.
Replacing legacy ATE systems supporting long-term mil/aero programs can be a daunting task. The goal is maintaining or improving the test coverage and diagnostic capability of an existing TPS. In addition, cost and time considerations are critical to the upgrade decision. The ideal TPS migration solution considers cost and time equally. Cost often includes the investment in a replacement ATE system as well as costs associated with the TPS test fixtures. Often the costs associated with the fixtures outweigh the capital equipment investment, making existing TPS retention a significant purchasing requirement. In addition to the condition and dependability of the legacy fixtures, alignment of the legacy to replacement ATE hardware architectures is critical for good return on investment (ROI) after the test upgrade.
Time considerations for TPS migration impact cost associated with the debug/acceptance of each TPS on the replacement ATE system and the timeline for new ATE system deployment to the manufacturing or repair process. The ideal TPS migration optimizes time spent by matching the hardware architecture, reducing/eliminating manual test re-writes and fixturing modifications. Equally important, the TPS migration software’s efficiency will minimize TPS debug on the target ATE system.
TPS generated using LASAR simulation present a unique set of complex challenges. Most importantly, the user may require either the translation from the legacy ATE system or directly from LASAR simulation. Considerations for a successful LASAR migration include Go/NoGo and diagnostic capability, matching complex structures such as Do-Loops/Subroutines, analog/parametric tests, and retention of post-simulation debug.
Matching Hardware Architecture: Legacy to Replacement Test Equipment
Before successful TPS software migration can occur, the replacement ATE system must be able to reproduce the legacy systems’ performance. Of particular interest is its ability to accommodate the digital I/O levels, digital timing specifications, analog/parametric capabilities, and guided probe and fault dictionary.
Modern ATE systems are generally designed to accommodate the requirements of modern printed circuit boards (PCBs), i.e., data rates greater than 25 MHz, high-density channel cards, etc. These test systems often have difficulty dealing with the simpler test requirements of older technology, such as guided probe and parametric tests.
If the hardware architecture is not adequately matched, TPS migration becomes increasingly complex, if not impossible. Once the replacement ATE hardwareis matched, the channel count can be configured to accommodate each TPS’s needs, while also considering what future TPS may require. The replacement ATE should be scalable, allowing increasing the channels by simply adding more channel boards.
Migrating to a Modern Tester: Case Study
To maximize ROI during a legacy migration, replace multiple legacy systems with a single test system. One high-reliability (mil/aero) company was able to migrate TPS in support of a naval system from a GenRad 1796 test system and a GenRad 2750 test system to a single Seica Valid ATE system running Viva software. In addition to cost savings generated by avoiding a second ATE system purchase, cost savings were also realized in the ongoing support of the single replacement ATE system. Due to the investment in new fixturing, this hi-rel company wanted to re-use the legacy test fixtures from the GenRad testers. In addition to the replacement cost considerations, lacking documentation from some legacy test fixtures require extensive reverse engineering to reproduce.
Migration adapter boxes (MAB) were designed to adapt the Legacy GenRad test fixtures to the Seica Valid ATE test system.
Third Party Intrument Integration
Depending on the functional requirements of the target TPS, legacy ATE systems were typically configured with one or more third-party instruments. Seamless hardware and software integration of the instrument within the replacement ATE will minimize debug during TPS migration. When integrating the hardware of third-party instruments, include connection of the instrument into the replacement ATE and the ability to connect the instrument into any of the system channels for stimulus/measurement on any of the unit under test (UUT) pins.
Figure 1. LASAR migration diagram.With the legacy systems predating instrument communication standards such as IVI or even IEEE-488.2, support of the legacy instrument command set requires translating the original test set instructions. The replacement ATE system should include a user-friendly driver facility to accommodate any unique instruments encountered.Migration Considerations
With LASAR Simulation System historically the U.S. defense industry's standard for digital test program set development, large numbers of TPS exist on legacy systems that soon could, if not already, face EOL issues. These are candidates for migration to a replacement ATE system.
The first consideration for TPS using LASAR simulation is whether local modification (or extensions, like memory tests) were performed on the legacy ATE system. If so, direct migration from the LASAR LSRTAP files would not produce the final version of the TPS released on the legacy system. Such an approach, in fact, makes subsequent debugging difficult (LSRTAP files are non-ASCII-based and therefore unreadable during a debug situation). New migration tools** can directly translate from the LASAR L2POST-generated .SYM file. This file is ASCII-based, readable in debug. Direct conversion from the legacy L series ATE system of the .SYM file can also contain any local modification that may have occurred on the legacy ATE during debug, creating a true representative of the released TPS program.
Migrating digital simulation files often is not the end of the migration task. Non-simulation tests, including analog (voltage stimulus/measure and timing) or memory testing, also must be ported to the new test system. Therefore, the migration tool must support the full complement of tests on the legacy TPS to minimize the debug effort post-transition. A graphical environment tool should be included in the replacement ATE to assist in the typical debug effort involved in analog migration. The optimal environment should also include the capability to implement modifications in real time and to automatically update the source files with proven stimulus/measurement settings for a given test.
Most migration solutions are irreversible “one-shot” programs. A better software architecture has provisions to back-annotate modifications into the LASAR .PAT language. The advantage is twofold. First, if modifications are done during debug on the functional test platform, the user can bring them back into LASAR and either verify that the fault coverage has not been degraded or confirm an improvement. Second, the final test program is back-annotated on LASAR and can be used at a later time if substantial modifications to the board should occur, which alternatively would require regeneration of the test program on an unsupportable legacy test platform. Figure 1 is a schematic representation of the architecture of the software migration process.
Figure 2. Programming language compatibility.
TPS software program migration is the first step in supporting the UUT on the new ATE system. Often, guided probe diagnostics and fault dictionary were integral to LASAR-based legacy systems. They were vital in successful troubleshooting of a UUT to locate the faulty device on the board. Retention of these legacy diagnostics is critical in supporting the UUT on the replacement ATE platform. It is of no benefit to fail a faulty UUT if there are no means to automate the troubleshooting process on the ATE system.
To guide the operator during production test to troubleshoot and localize a failed UUT to a single component, the migration environment must leverage the entire digital waveform database (including simulated internal nets) from the migrated TPS (from either the LASAR simulator or directly from the L series tester). Figure 2 shows an example of a migrated digital simulation including internal net waveforms.
The digital waveform tool can be used to display digital stimulus and measure, but it can also be used to learn the response on a given I/O pin or an internal net of the board, further enhancing diagnostic capability.
Several factors in the TPS migration process will increase the debug complexity and complicate the acceptance of the TPS on the new test platform. Foremost is the validation process of ensuring that the migrated TPS is equal or better than the original TPS for accuracy and test coverage. The complexities of modern test programming languages and environments make an apples-to-apples comparison difficult. Of equal importance is documentation of the migrated software, including retention of any comments in the legacy test program.
Figure 3. Legacy code to migrated code comparison.With object-oriented language compatibility in the tester’s programming language, an apples-to-apples comparison is possible. Figure 3 shows an excerpt of an L200POST.SYM file and the migrated .PAT file in the Viva environment. This example demonstrates a similar command structure, but also shows the comments from the legacy file in the migrated file (this significantly increases the debugging efficiency, especially if manual modifications were made in the legacy test program).
As discussed, the optimal replacement test system for any TPS migration, including LASAR, includes considerations for hardware compatibility but also flexibility for future TPS development and ongoing support. A complete solution combines ATE and TPS migration. Partial solutions involve TPS migration on third-party hardware.
With the complexities of TPS migration and the uniqueness of each specific project, careful consideration must be made during the entire migration effort. Replacement ATE hardware and fixtures costs are often core considerations. Of equal importance, especially if there are a large quantity of TPS to migrate, are the hidden costs that can be alleviated by proper alignment of the legacy ATE hardware to the new ATE platform and also with effectively and efficiently migrating the TPS software.
Figure 4. Guided probe diagnostic capability.
Optimal migration software retains complete No/Go and diagnostic capabilities, offers maximum migration compatibility (minimizing manual intervention and debug effort), and supports complementary tests (analog, timing, memory) and post-simulation modifications (LASAR TPS with manual debug on tester). The migration tool must also be flexible and adaptable to accommodate the varying degree of unique legacy migration challenges that inevitably occur. Lastly, the replacement ATE system should be considered as a future test platform with capabilities to enhance existing programs or develop new test programs for additional products.
*Legacy test platforms include: GenRad, Teradyne, Computer Automation, Schlumberger, Factron, and others.**Data provided is based on the Seica Viva LASAR migration solution.
Robert Peet may be contacted at SEICA Inc., 50A Northwestern Drive, Suite 10, Salem, NH 03079; (603) 890-6002; email@example.com.
The data for this article was originally presented at IEEE’s Autotestcon - Systems Readiness Technology Conference. Information on the 2010 Autotestcon conference is available at http://www.autotestcon.com/main/.