Articles and white papers
 
 
Y o u r  c o m p a n i o n  i n  p r o d u c t i o n  t e s t i n g
 
 
Articles and white papers
 
 
Plug and Play Production Testing

 
Yield and DPMO - what can they tell us

 
Utilizing Cpk in functional testing

 

 
 
 

Plug and Play Production Testing

(2/3)

Ad-hoc solutions
 
Data management problems have been solved various ways. One is to collect test data into test system hard disk. This data is then occasionally copied from there to OEM engineers. Not very real-time, but some statistics of test results is available.

Some OEM companies are implementing heavier systems and they bring their own test network maybe with even servers to EMS factory. Functional test results are then transferred daily or more often to OEM company. This way data can be easily uploaded to OEM data storage for analysis purposes. I wonder if this is practical from EMS point of view, when maybe several OEMs bring their separate networks to the factory. And test data is not available for EMS.

One way is of course to connect OEM test system to EMS factory network and collect the data to EMS servers, maybe also deliver from there to OEM. The interface is usually problematic when tester is not talking with data system. Of course this can be solved with some adaptation work.

Also various combinations of these methods are used. Even if you do lot of work to integrate tester to the local data system, that solution is valid only as long as OEM is using this certain EMS. When OEM wants to transfer production elsewhere, this adaptation is probably useless and you have to start over.

The solution alternatives above are focusing in management of test results and do not support defect data management. Defect data is also important to both, EMS and OEM engineers. They need defect statistics to really understand nature of problems.

Collecting reliable defect data requires closed repair loop. That means that when a test fails, test system sends information to database of the failing test(s). Person who is doing faultfinding enters then detailed cause of the failure (e.g. R2319 missing) to the data system. After that rework is done and product is re-tested. Defect information is validated only if product passes the test after repair. If re-testing fails, this loop runs again. All this means that we need working interaction between test system, rework bench and data system. Naturally re-testing is not done when visual inspection methods (e.g. AOI, AXI) are used; there we have to trust in information which repair person enters.

Bookmark and Share


 
Previous page <- -> Next page 

Shortcuts
- Front page
- Articles
- Test Efficiency Analysis Tool
- Cpk Calculator
- DPMO Calculator
 
 

 
 

Contact information
Testele.com is not liable for any damages arising of the use of tools, methods and guidelines in this site.