Underlying Hardware and Software Architecture Changes and Their Effects on TPS Software

Today's fast paced world of ever changing Commercial-Of-The-Shelf (COTS) hardware and software architectures creates a quandary in that the end-user must be cognizant of these effects on their own legacy based system when embracing a new design. The advantages of moving to a newer and sleeker system surely outweigh the complexities of attempting to maintain an older system especially when obsolescence concerns make it virtually impossible to maintain the existing design. But, in moving to a new platform the user must be cognizant of the effects it will have on existing Test Program Set (TPS) software when in most cases this TPS software cannot be modified extensively because of the initial investment spent in creating it and getting it to execute on a specified piece of Automated Test Equipment (ATE). In most cases, the Unit Under Test (UUT) hardware, the Interface Test Adapter (ITAs) hardware, and the existing TPS software will not be modified to run on a new piece of ATE equipment so any timing-related problems uncovered with the new design will need to be corrected within the TPS software or underlying driver software housed on the new host computer. Most, if not all, of the timing problems will be uncovered during the integration and regression testing of the TPS software with the new ATE architecture. There are other concerns that will be discussed in this paper such as compilation and run time problems that the user will most likely encounter as part of the shift to a more modern ATE design. The main thrust of this paper will be to encapsulate and explain the realities with respect to TPS software as to what may happen when moving from a legacy-based ATE platform to a more modernized version of the ATE architecture.