Manufacturing Diagnostic Tool Manufacturing Diagnostic Tool An on - - PowerPoint PPT Presentation

Slide 1 EBTW 2005, Tallinn, Estonia

EBTW05 EBTW05

Manufacturing Diagnostic Tool Manufacturing Diagnostic Tool An An on board

• n board low cost diagnostic test solution

low cost diagnostic test solution

Slide 2 EBTW 2005, Tallinn, Estonia

EBTW05 EBTW05

Agenda

Challenges in the current Test Environment A Solution developed: MDT Summary & Conclusions Questions

Slide 3 EBTW 2005, Tallinn, Estonia

EBTW05 EBTW05

Challenges in the current environment

Less time to develop test solutions

Shorter Product Life cycles

Need for test solution early in development life cycle

(e.g. prototype stage)

Need for test solution that is re-usable through lifecycle stages Need to cut test costs

Test time Test equipment

Make better use resources

re-usable test code better leverage from existing work done by component suppliers and internal software groups

PROTO Pre Production Production Debug/ Repair Development

Slide 4 EBTW 2005, Tallinn, Estonia

EBTW05 EBTW05

How does MDT address these Challenges ?

An Example: Reduce Cost in Manufacturing / Production I will talk through typical process & highlight issues

What is MDT ?

Where it fits What it does Benefits it brings

Slide 5 EBTW 2005, Tallinn, Estonia

EBTW05 EBTW05

The typical manufacturing process flow is In Circuit Test (ICT) followed by Functional Test (FT).

ICT

• Bed of nails tester
• Check Component placement & value
• Limited functionality check
• No testing via board connectors

FT

• First time unit is powered up
• Running application Software
• Passing traffic in real world scenario
• High cost Equipment
• Typically long test time

FT Other ICT

Slide 6 EBTW 2005, Tallinn, Estonia

EBTW05 EBTW05

A problem existed however with this approach. The FT stage was the first time the cards were powered-on. What if they don’t power on ? This test stage involves complex & costly test equipment & failures of this nature impact capacity.

Slide 7 EBTW 2005, Tallinn, Estonia

EBTW05 EBTW05

A quantity of cards could be

‘no-boot’ “Power On Self Test” (POST) failures.

ICT FT OTHER NO BOOT PASS PASS Functional FAIL Debug FAIL >Difficult to debug >Not really functional fails

It seemed logical to add a stage between ICT & FT

Slide 8 EBTW 2005, Tallinn, Estonia

EBTW05 EBTW05

Where does MDT fit ?

S T IN G E R F S + W

• rkstatio

n 16 x rs232 cab les S erial /R S 232 eth ern et S erial /R S 232

Screen / Diagnose power-up failures Low cost basic equipment Test multiple units in parallel

Slide 9 EBTW 2005, Tallinn, Estonia

EBTW05 EBTW05

But What does MDT do?

The MDT code is responsible for

Presenting the user with a menu to allow them to run sets of tests to Test all devices on the card. Test a particular subsection of the card. Test individual components on the cards Reporting errors in a user-friendly format useful to a test operator or debug technician. Inform user which component has failed using the components reference designator (e.g U4)

Slide 10 EBTW 2005, Tallinn, Estonia

EBTW05 EBTW05

Typical UUT

Brings up card in minimal mode (bypass P.O.S.T) Provides ability to Test all components Target specific components

Slide 11 EBTW 2005, Tallinn, Estonia

EBTW05 EBTW05

What the user sees

Slide 12 EBTW 2005, Tallinn, Estonia

EBTW05 EBTW05

A bit of history

A point to note about MDT is that it has gone through 2 distinct stages or evolution,

Run as Standalone bin file Run under an Operating System

The reasons for doing this will be explained

Slide 13 EBTW 2005, Tallinn, Estonia

EBTW05 EBTW05

Why run under an OS ?

One of the main aims of MDT

• Shorten Test Development Time

Code re-use is one of the main ways to achieve this

• Application Code
• Test Code
• Vendor API Code

Vendor API Code -

• Software supplied by vendor with their chipset

Software supplied by vendor with their chipset

Vendor API integration is a main challenge

• This has be be done for Application SW
• By moving under same OS as application code we can re-use this
• The effort to integrate the component vendor API’s is done only once and these API’s are then

available for use both within Application Software and MDT diagnostic software.

The main benefits from this integrated approach are:

• Code re-use resulting in reduced development time.
• More consistent testing. (Diagnostic test is using same low level drivers and same basic operating

system functionality)

Slide 14 EBTW 2005, Tallinn, Estonia

EBTW05 EBTW05

Integration of MDT into an OS

Integration of MDT into an OS.

Operating System Component Vendor API 1 Application Code ( including User Interface) MDT Code Api wrapper Code (generic Frameworks) Component Vendor API 2 Component Vendor API 3 Utility Code File System etc Various higher level OS Code Blocks

Slide 15 EBTW 2005, Tallinn, Estonia

EBTW05 EBTW05

Code Structure

The MDT has its own subdirectory under the OS and is further subdivided as follows: MDT “Root” : common code “Menus” : menu framework “Utils” : utility code “Generic Tests” : test frameworks Card directories : unique to card The MDT code structure is designed to promote code re-use

Slide 16 EBTW 2005, Tallinn, Estonia

EBTW05 EBTW05

Challenges .Were they addressed?

Less time to develop test solutions

Code Reuse

Need for test solution early in development life cycle

Code reuse

Need for test solution that is re-usable through lifecycle stages Need to cut test costs

Low cost Test equipment & concurrent Testing Pre screen for FT

Make better use resources

better leverage from existing work done by component suppliers and internal software groups

PROTO Pre Production Production Debug/ Repair Development

Slide 17 EBTW 2005, Tallinn, Estonia

EBTW05 EBTW05

One Last Item

In order To enhance the benefits of MDT for a production production scenario scenario it is integrated into a GTS (Generic Test System) that provides:

An intuitive GUI A data-logging framework. Concurrent testing of multiple cells

Slide 18 EBTW 2005, Tallinn, Estonia

EBTW05 EBTW05

GUI & Data Collection

G T S F r a m e w o r k D a ta b a s e G U I C A R D x W r a p p e r S c r ip t O S o n C a r d M D T r u n n in g u n d e r O S C A R D x W r a p p e r S c r ip t O S o n C a r d M D T r u n n in g u n d e r O S C A R D x W r a p p e r S c r ip t O S o n C a r d M D T r u n n in g u n d e r O S

Slide 19 EBTW 2005, Tallinn, Estonia

EBTW05 EBTW05

Summary & Conclusions

Manufacturing /Cost of Test

Increased capacity. Detect failures early in process thus increasing yield at functional test.

Debug/Repair

Provide accurate failure information to component (Reference Designator) level

Test Development

Reduced test development time Eliminate duplication of effort

Engineering Knowledge

Better detailed knowledge of components

Closer Links to other groups

Component Vendor FAE and SW engineers Internal Application SW developers

Slide 20 EBTW 2005, Tallinn, Estonia

EBTW05 EBTW05

• Questions ?

Questions ?

Slide 21 EBTW 2005, Tallinn, Estonia

EBTW05 EBTW05

• Backup Slides !

Backup Slides !

Slide 22 EBTW 2005, Tallinn, Estonia

EBTW05 EBTW05

Slide 23 EBTW 2005, Tallinn, Estonia

EBTW05 EBTW05

Slide 24 EBTW 2005, Tallinn, Estonia

EBTW05 EBTW05