1. Module Testing at UCSB: Simulated Production 11-04
Derek Barge
On behalf of the UCSB testing group

2. 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

3. 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

4. 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

5. 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.

6. 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

7. 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