Legacy test systems for PCB test and repair (Guest commentary)
Mark Harding, Digitaltest -- Test & Measurement World, 11/5/2007 8:46:00 AM
Two major categories of legacy issues predominate in electronics test and repair: the “old legacy system issues” and the “new legacy system issues.” Old legacy issues primarily affect repair, while new legacy issues center on correlation between test resources at the target volume manufacturing facility and the development center.
Old legacy system issues
Many areas of manufacturing face the challenge of maintaining older platforms, but manufacturers testing assembled PCBs face a number of unique challenges that require test processes to be available many years after the original manufacturing date. In addition to those products that naturally have a long manufacturing life span, sectors such as industrial control, military, aerospace, infrastructure, medical, and automotive products may require test and repair support many years after the manufacturing platforms were scraped.
The old platform legacy issue can be seen most clearly at repair centers, where products are transferred for on-going customer support and maintenance. At these sites, many old platforms from differing vendors are transferred with their test interface fixtures, with the expectation that these will provide diagnostic test for field returns. But this strategy has some fundamental flaws:
• Production test processes are developed to address production defects and are not necessarily capable of finding field-failure issues. So most will require some rework to address the differing fault spectrum.
• Expectations that platforms and fixtures transferred from production sites will be of sufficient working quality to be readily usable are not always fulfilled.
• Assumptions that the transferred platform is still supported from the original vendor are often unfounded. Since the decline of the capital equipment market after 2000, many of the older platforms are now no longer supported.
• Trust that the skills exist within the repair center to support a diverse range of platforms and test development environments is often misplaced. Older test platforms used Unix and other compiled test languages, which may not only require unique development environments but also programming skills that are increasingly rare.
The combined result of these issues is that the on-going support of the many legacy test platforms consumes ever increasing amounts of cash and skills, making most repair centers unviable business operations without significant input from a parent organization.
New legacy issues
Trends within the electronics manufacturing industry are pushing more business to lower cost geographies for volume production after the initial product development has been completed within the originating new-product introduction center. Test resources at the target volume manufacturing facility will need to have the same test platform as that used at the development center. Of course, if the target manufacturing centre is known in advance, steps can be taken to minimize the test transfer task. But volume manufacturing sites are usually selected by purchasing teams based largely on material pricing, delivery, and quality and not for their absolute process compatibility.
Globalization trends are also joining together key players within market segments like aerospace and datacom. Each of these players, with their own test strategies and preferred test platforms, are now forced to make decisions on which platforms to drop in the interests of compatibility. Such decisions are often postponed as being too sensitive and difficult, further compounding the legacy issue.
Solving legacy test issues
It can be a daunting task to rationalize test strategies for repair centers and newly merged organizations faced with an existing large base of test platforms and test fixtures. But unless some steps are taken to reduce the platform support demands, then engineers will be continually distracted from their primary task of supporting customers, with the demands for internal test support.
A “step by step” approach
There are few “silver bullet” solutions for complex engineering tasks. But a measured “step by step” approach will begin to yield results remarkably quick.
The first step is to fix a general test strategy that can be applied to the majority of the test tasks. This may be to utilize an existing platform, but is more likely to be more productive when a test platform is chosen that is designed to address the specific challenge. Digitaltest has researched the demand within this market while developing the MTS300 Sigma and determined that these critical features are needed for successful test application migration:
• a non-multiplexed test pin architecture to ensure that existing “real pin” multiplexing issues can be accommodated,*
• a universal interface capable of accepting fixture converters from all the leading ICT platforms to ensure that the investment in existing costly test fixtures can be protected and reused in future test strategies, and
• software conversion tools that provide an automated and consistent test application conversion process (The MTS300, for example, behaves like a “neutral platform” that can emulate existing test programs).
Following the test-platform selection, the next step is to establish a transfer program in order of priority, which could depend on factors such as these:
• the fragility of the existing test platform (with regard to age, spares, support, etc.),
• the cost of supporting the existing test platform,
• the future demand by product type,
• the quality of the existing test application (can improvements be made during the transfer?),
• the ease of transfer, and
• available engineering resources.
By taking these steps, and with careful planning, measurable results should be evident soon after implementation. Ensuring the present confused state of multiple and obsolete test platforms is rationalized down to a commercially sustainable level and at the same time protecting the considerable investment in test fixtures and applications.
Mark Harding is GM of US operations for Digitaltest.
*Here a note on multiplexing might aid our understanding: Many test platforms, including those from HP/Agilent and GenRad/Teradyne, use multiplex test architectures. The multiplexing of costly resources was intended to lower the cost per pin by having each “real pin” (those with full analog and digital drive and sense capability) shared across multiple test-head pins. The test engineer needs to ensure the test pin allocation was correctly spread over the available “real pins” for each test. Unfortunately there was no standard for this multiplexing of test pins, meaning that most test applications cannot simply be loaded onto an alternative test platform that also has a multiplexed architecture.
Talkback
Related Content
Related Content
Sponsored Links
TMW Resource Center
Browse Resources by Type:
- Model Z580 Hand held High Accuracy LCR meter data sheet
Protek, Inc. | Data Sheet
VIEW NOW
Protek, Inc. | Data Sheet
VIEW NOW
Tektronix | Web Event
VIEW NOW
View More
