Adaptable test program set development ensures an adept test program

Abstract

Perhaps, at no other time in recent history, has adaptability or alter nativity or options been more important than it is now. With the varied technologies on each Unit Under Test (UUT) and the advent of new technology we must be very adaptable with Test Program Set (TPS) Development. Also, Automatic Test Equipment (ATE) capability is increasing exponentially, technology never stands still. Most certainly our TPS Development environment supports the need for the development of adaptability or alter nativity. Even with Automatic Test Equipment (ATE) “There was also evidence that IFTE, as an adaptable maintenance system that can support multiple platforms, can improve system readiness and availability, resulting in significant cost savings”1. We should promote process adaptability throughout the life-cycle of a system so technology can be used as needed. An Adept TPS is noticeable by the Test Program's characteristics. Characteristics of an Adept TPS are code refinement, test structure, instrument usage, ITA routing, test stability, test time, precision measurements, test requirements inclusion, % detect (as an automated measurement), test type, ITA design, and overall quality. Essentially, the bottom line is the proper use of instruments and technology (both hardware and software) as optimized by best practices are factors associated with an Adept TPS. Anytime shortcuts are taken or inconsistencies are exposed during TPS review or sell off it becomes apparent the TPS does not have the characteristics of an Adept TPS. In the past (not too long ago), it was incredibly frustrating to fix a test void using a legacy ATE with an active component ITA. It is beneficial to develop a set of guidelines for applying adaptive or alternative TPS development. How does a TPS developer become an adaptable/alternative TPS Developer? Actually, this is accomplished by the issuing of a best practices document, experience and sharing skill and know-how. Knowhow and sharing skill is often acquired by attending test conferences. Re-Host problems can arise when a test is commented out because the legacy TPS developer might lack the know how to integrate the test. Also, ATE problems play a critical part in TPS integration, noisy ATE or low performance instruments or even calibration play critical roles. The integration of certain tests in legacy ATE requires active components in the ITA due to inadequate ATE resources. So, do you forget about the test as outlined in the Test Requirements Document or do you integrate the test and make it work. When you review the legacy TPS and discover a test commented out, you wonder how this happened. Sometimes a test is commented out by the legacy TPS developer and sometimes they are commented out by the legacy TPS software supporter. This is one of the reasons why a re-host is often acknowledged as new development. No matter who commented out the test code, it is the responsibility (as per the Program Manager's direction) of the Re-host engineer to integrate the test. This paper will discuss adaptability or alternatively and other critical factors associated with TPS development and re-host. Also, discussed is the use of advanced technologies to integrate previously commented out tests.