{"title":"An overview of the ATML family and related standards","authors":"C. Gorringe, M. Seavey, T. Lopes","doi":"10.1109/AUTEST.2011.6058783","DOIUrl":"https://doi.org/10.1109/AUTEST.2011.6058783","url":null,"abstract":"The “IEEE Full-Use Standard for Automatic Test Markup Language (ATML) for Exchanging Automatic Test Equipment and Test Information via XML” (IEEE Std 1671™-2010) and all its ‘dot’ standards have been published and are available from the IEEE. The ATML standards working group are currently revising these trial use ‘dot’ standards to match their current development eXtendable Markup Language (XML) schemas in line with the full use IEEE Std 1671. The “Common” ATML XML schemas are posted to an IEEE download site on the World Wide Web, available for download and use. In short, the ATML standard and it's ‘dot’ companions are now published, available, and their associated XML Schemas are downloadable from the Web, and in use across industry.","PeriodicalId":110721,"journal":{"name":"2011 IEEE AUTOTESTCON","volume":"38 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2011-10-24","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"114597579","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
Huxun Chen, DeQing Chen, Jinlin Ye, Weizhou Cao, Lei Gao
{"title":"An integrated Automatic Test Generation and executing system","authors":"Huxun Chen, DeQing Chen, Jinlin Ye, Weizhou Cao, Lei Gao","doi":"10.1109/AUTEST.2011.6058726","DOIUrl":"https://doi.org/10.1109/AUTEST.2011.6058726","url":null,"abstract":"This paper presents an integrated Automatic Test Generation (ATG) and Automatic Test Executing/Equipment (ATE) system for complex boards. We developed an ATG technique called Behavior-Based Automatic Test Generation technique (namely BBATG). BBATG uses the device behavior fault model and represents a circuit board as interconnection of devices. A behavior of a device is a set of functions with timing relations on its in/out pins. When used for a digital circuit board test generation, BBATG utilizes device behavior libraries to drive behavior error signals and sensitize paths along one or multiple vectors so that a heavy and complicated iterating process can be avoided for sequential circuit test deductions. We have developed a complete set of test executing software and test supporting hardware for the ATE which can use the BBATG generated test data directly to detect behavior faults and diagnose faults at the device level for complex circuit boards. In addition, we have proposed and implemented useful technique, especially Design For Testability (DFT) [1][2] application technique on the integrated system, so the test generating/executing for complex boards with VLSI can be further simplified and optimized.","PeriodicalId":110721,"journal":{"name":"2011 IEEE AUTOTESTCON","volume":"22 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2011-10-24","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"131197528","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
{"title":"Managing sources of error in automated test systems","authors":"P. Packebush, C. Heide","doi":"10.1109/AUTEST.2011.6058730","DOIUrl":"https://doi.org/10.1109/AUTEST.2011.6058730","url":null,"abstract":"Identifying sources of error in an automated test system is rarely trivial. When Modular Instruments are a part of the solution, additional complexity can arise due to software dependencies, and error correction techniques implemented in the Modular Instrument. This paper addresses this subject by explaining possible sources of error induced by Modular Instruments, and strategies for managing them in an automated test system.","PeriodicalId":110721,"journal":{"name":"2011 IEEE AUTOTESTCON","volume":"148 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2011-10-24","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"133526461","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
{"title":"A transportability microcosm as an enabler for a family of testers","authors":"R. Marion","doi":"10.1109/AUTEST.2011.6058756","DOIUrl":"https://doi.org/10.1109/AUTEST.2011.6058756","url":null,"abstract":"The paper will analyze a single simple instrument type to focus on ensuring transportability across a family of automated test equipment (ATE) testers. Transportability analysis and multiple hosting across a family of testers are important topics in advanced test and diagnosis of electronic assemblies. The ATE instrument type selected is direct current (DC) power supplies, where application of a DC voltage is complicated by impedance, transient and load characteristics. The ideal condition of a test program set (TPS) is the ability to tolerate the conditions described, but that condition is rarely achieved. Therefore, the family of testers must exhibit consistent behavior regardless of instrument manufacturer.","PeriodicalId":110721,"journal":{"name":"2011 IEEE AUTOTESTCON","volume":"67 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2011-10-24","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"114139040","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
{"title":"Polymorphic Analog Instrument Environment","authors":"D. Lind, M. Haney, Ryan Healey","doi":"10.1109/AUTEST.2011.6058765","DOIUrl":"https://doi.org/10.1109/AUTEST.2011.6058765","url":null,"abstract":"this paper discusses the architecture of an environment for analog tests that is designed to work on a variety of hardware platforms. It employs a resource manager that understands the resources that are available and manages their allocation. The particular brand of instrument is not important, as long as the instrument contains the necessary capabilities. The Analog Instrument Environment contains instrument graphical user interfaces that morph to reflect the capabilities of the target hardware. There is a UI with a common look and feel that queries the hardware for its capabilities, and allows real time interaction with the hardware using the particular instrument's native nomenclature. The environment lets you define analog test steps consisting of a sequence of steps that control and read back results from the instrumentation available. You can run and debug the step, and you can generate the code necessary to run the steps in a Test Program Set (TPS).","PeriodicalId":110721,"journal":{"name":"2011 IEEE AUTOTESTCON","volume":"138 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2011-10-24","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"128273752","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
{"title":"A subsystem that behaves as an LXI instrument","authors":"Brandon Thorpe","doi":"10.1109/AUTEST.2011.6058743","DOIUrl":"https://doi.org/10.1109/AUTEST.2011.6058743","url":null,"abstract":"This paper describes an intelligent subsystem that integrates into a larger test system as if it were a single complex instrument. Actually, the subsystem contains a controlling embedded PC and various instruments that conform to the PXIe test standard working in tight coordination to perform complex tasks. The test station computer communicates with the subsystem with a high-level IVI driver via Ethernet.","PeriodicalId":110721,"journal":{"name":"2011 IEEE AUTOTESTCON","volume":"155 ","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2011-10-24","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"134161812","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
{"title":"An in-depth look at the radio frequency ground support equipment for the radiation belt storm probes mission","authors":"J. Bitman","doi":"10.1109/AUTEST.2011.6058725","DOIUrl":"https://doi.org/10.1109/AUTEST.2011.6058725","url":null,"abstract":"The Radiation Belt Storm Probes, twin spacecraft that will study the Earth's radiation belts, will be launched in 2012. The two satellites are being designed and built for the National Aeronautics and Space Administration by The Johns Hopkins University Applied Physics Laboratory. Before launch, the spacecraft will undergo significant ground testing, much of which will be automated. This paper describes the design, fabrication, and use of the ground support equipment used to test the radio frequency communications subsystem. It discusses issues that arose during design and testing, describes how they were resolved, and presents recommendations for future test programs on the basis of lessons learned.","PeriodicalId":110721,"journal":{"name":"2011 IEEE AUTOTESTCON","volume":"12 1 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2011-10-24","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"124796819","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
{"title":"Comparing software design for testability to hardware DFT and BIST","authors":"J. Alanen, L. Ungar","doi":"10.1109/AUTEST.2011.6058776","DOIUrl":"https://doi.org/10.1109/AUTEST.2011.6058776","url":null,"abstract":"Software is replacing hardware whenever possible, and this trend is increasing. Software faults are every bit as pervasive and difficult to deal with as hardware faults. Debugging software faults is manual, time consuming, often elusive and since they affect all systems deployed, most often they are critical. Design for Debugging would ensure that a software package can be readily debugged for any software fault. A comprehensive software test, however, is intended to eliminate the need for ad hoc debugging and ideally all “bugs” (we call software faults) would be caught and identified by the software test. Thus, it is imperative that the software community adopt means to ensure that software components are designed in a way that will detect and isolate software faults. This requirement is familiar to designers of hardware systems. Could the discipline of hardware design for testability (DFT) and Built-In [Self] Test (BIST) apply to software design for testability? The purpose of this paper is to discuss how many of the testability requirements and techniques for hardware DFT can be applied to software.","PeriodicalId":110721,"journal":{"name":"2011 IEEE AUTOTESTCON","volume":"6 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2011-10-24","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"125158931","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
{"title":"Supporting a family of test program languages using a single open markup language","authors":"S. Wegener","doi":"10.1109/AUTEST.2011.6058753","DOIUrl":"https://doi.org/10.1109/AUTEST.2011.6058753","url":null,"abstract":"Having a single structure for representing test program data is the cornerstone for a common architecture of a modular system that includes test program development, test program data collection, test program execution, collection of runtime data and interaction with intelligent sequencers. A common open markup language leads to common tools for data collection, test program editing, and a common runtime engine. Boeing has a fielded, open and scalable format currently supporting a single test program language. This paper will examine the use of this structure for storing other test program languages and how it fits into a common architecture approach. Presented is the concept of a simplified notation for automated test system programs (SNAP) that is human-readable yet easily converted to machine-readable extensible markup language (XML).","PeriodicalId":110721,"journal":{"name":"2011 IEEE AUTOTESTCON","volume":"54 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2011-10-24","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"122466066","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
{"title":"When should intermittent failure detection routines be part of the legacy re-host TPS?","authors":"L. Kirkland","doi":"10.1109/AUTEST.2011.6058722","DOIUrl":"https://doi.org/10.1109/AUTEST.2011.6058722","url":null,"abstract":"Intermittent failures are failures that do not manifest themselves all the time. The fact that they are sometimes there and sometimes aren't can make them very difficult to analyze.1 Some of the most difficult to diagnose faults are intermittent. It is very difficult to isolate intermittent faults which occur with low frequency.2 Intermittent electrical faults, as a rule, are notoriously difficult to detect. Sometimes an intermittent short or open circuit may leave visible signs of overheating or micro-arcing on a printed circuit board or a connector, but at other times damage may be on such a microscopic scale that it is likely to go undetected.3 The inability to find anything wrong by trying to reproduce the incident is no guarantee of the detection of an intermittent fault. This paper will discuss various ways to detect intermittent failures. The paper will discuss the root causes of intermittent failures. Also, a discussion will take place that addresses why we must pursue new techniques, methods and technologies to detect elusive failures.","PeriodicalId":110721,"journal":{"name":"2011 IEEE AUTOTESTCON","volume":"3 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2011-10-24","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"114189735","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}