Module Testing at UCSB: Simulated Production 11-04 Derek Barge On behalf of the UCSB testing group
Purpose To show a testing rate of 30 modules per day can be comfortably sustained at UCSB To identify potential problems & bottlenecks: ARCS Software (requests for Aachen) ARCS Software configuration Mechanics & Logistics Test Checklists & data management Test automated uploading to TrackerDB Crowding in the Lab
Testing Rates 30 Modules Tested Tests & Rates 15 OB2, 9 OB1, 6 Stereo OB2 Simulated worst case scenario: Artificially high fault rate Mixed module types (OB1 & OB2) Tests & Rates A Total of 36 tests were performed (4 repairs, 1 unbiased, 1 with wrong cuts) Testing complete in 8 hours, 13 man hours 2.75 tests per man hour 4.5 tests per hour !!! 3.75 modules finished per hour, 2.3 per man hour Average test takes 26 minutes
Testing Results Grading: 28 Grade A 0 Grade B 2 Grade C (both failed) 26/30 Modules processed (passed or failed) on first test 24/26 passed 2/26 failed 1 CMN 1 with 11 opens due to problems bonding & 3 noisy channels 4/30 Modules needed repairs 6063: 2 expected pinholes, 1 unexpected open 6075: 1 pinhole, 1 expected short, 1 unexpected short, 2 expected noisy 6077: 3 expected pinholes, 1 unexpected pinhole, 1 unexpected open, 2 noisy 6079: 2 expected pinholes
Problems Encountered Mechanics & Logistics Software & Data Solder broke on adapter card, took ~ 20 min to fix DB relay down for 15 minutes, switched relay Flying wires need to be taped down to avoid damage Software & Data Minor software improvements from Aachen Should gain ~ 1 min per test and reduced bad test rate False flag rate 1 test in 1 mode falsely flagged good channel as a likely 1SO Incomplete bonding data Some unexpected opens were encountered, channels that could not be bonded were not entered in the DB. This was fixed immediately.
Success Stories Data Management Crowding in the Clean room New version of Module Checklist worked well 3 minor bugs discovered, mostly aesthetic More automation than previous version; only bad channels need to be entered Automatic uploading of module data via XML is implemented Half of the XML files uploaded successfully on first try Other half failed due to incorrect tool id for one stand, fixed and uploaded fine Crowding in the Clean room Clean room was not overcrowded Good communication between testing stations
Conclusions 30 modules per day is sustainable Could potentially test 36 PERFECT modules in a day Otherwise testing rate depends on rate of modules needing repair Simulated repair rate of 4/30 in this excercise = .13 ST qualification repair rate was ~ 1/10 = .1 HPK: about 1/30 modules have an expected fault, unexpected fault rate expected to be even lower for HPK Performace should improve with HPK silicon