Browse Prior Art Database

A Method to Identify and Report Each Failure on First Occurrence and Then Quarantine Each Failing Device During Device Test at Manufacturing

IP.com Disclosure Number: IPCOM000214947D
Publication Date: 2012-Feb-15
Document File: 4 page(s) / 419K

Publishing Venue

The IP.com Prior Art Database

Abstract

During a device test at manufacturing, a pool of same devices are tested together to determine the state of all the devices in the pool. A device is considered to be defective if any type of failure is detected on that device during the device test. The test program that tests a pool of devices concurrently typically uses many separate test streams to verify that the devices under test are operating properly. Because the type of devices being tested in manufacturing have already gone through normal device test and verification (in the test lab) before they are shipped to manufacturing, the devices are expected to work properly, and any device failure is most likely due to manufacturing defect(s). Therefore, the device test operator only wants to know if the device under test has passed all the test streams (not how many test streams failed and what the failures are) and to throw all the failing devices into the defective pile for further analysis sometime later.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 37% of the total text.

Page 01 of 4

A Method to Identify and Report Each Failure on First Occurrence and Then Quarantine Each Failing Device During Device Test at Manufacturing

However, the test operator currently does not have an efficient way to accomplish this task. So the test operator is left with only very time consuming and undesirable methods. The first method leaves it up to the test operator to figure out the defective devices after the device test run by blindly swapping test devices and re-running the device test repeatedly until the defective devices are isolated (guessing method). Another option the test operator has is to send the test program error output to the test program developer and then wait for the test program developer to get back after the test program error output has been analyzed and defective device(s) are identified (waiting method). The test operator normally uses the waiting method.

    In addition to the test operator, the test program owner as well as the device developers are typically most interested in the first failed test stream executed on the defective device because the first failure provides the best and unbiased data (i.e. the current error is not due to another previous error) to analyze the failure, and eliminates the extra time it would take for all involved developers to look through all subsequent failures of the defective device if the defective device is not quarantined after the first failure.

    This article shows a method to identify and report each failure on first occurrence and then quarantine each failing device during Device Test at manufacturing. This method would solve the problem for all parties involved - the device test operator, the device test program owner, and the device developers. The test program first executes
a test stream and then checks to see if a failure has occurred on the test device. If there is a failure, then the program reports the failed test device information to the test operator so the test operator can take appropriate action and log it on system log (if any) for later use. This is followed by collecting and printing all the relevant information of the failure for analysis and correction, and then quarantining the failing device by removing the failing device from the pool of devices under test. The test program then continues testing until either all test devices in the test device pool are found to be defective or all the test streams have been executed on all the good test devices in the test device pool. This method helps the test operator to pinpoint all the defective devices for every device test run and eliminates all the other very time consuming and undesirable methods like guessing and waiting methods. This method can also be used to test the devices for proper installation and operation after the machine has been installed or reconfigured at the customer's site.

    This method would solve the problem for all parties involved - the device test operator, the device test program...