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

EBTW05 EBTW05 Manufacturing Diagnostic Tool Manufacturing Diagnostic Tool An on board on board low cost diagnostic test solution low cost diagnostic test solution An EBTW 2005, Tallinn, Estonia Slide 1

EBTW05 EBTW05 Agenda � Challenges in the current Test Environment � A Solution developed: MDT � Summary & Conclusions � Questions EBTW 2005, Tallinn, Estonia Slide 2

EBTW05 EBTW05 Challenges in the current environment � Less time to develop test solutions � Shorter Product Life cycles Development � Need for test solution early in development life cycle � (e.g. prototype stage) � Need for test solution that is re-usable through lifecycle PROTO stages Debug/ Repair � Need to cut test costs Pre Production � Test time � Test equipment � Make better use resources Production � re-usable test code � better leverage from existing work done by component suppliers and internal software groups EBTW 2005, Tallinn, Estonia Slide 3

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 EBTW 2005, Tallinn, Estonia Slide 4

EBTW05 EBTW05 � The typical manufacturing process flow is In Circuit Test (ICT) followed by Functional Test (FT). ICT -Bed of nails tester ICT -Check Component placement & value - Limited functionality check -No testing via board connectors FT FT - First time unit is powered up - Running application Software - Passing traffic in real world scenario - High cost Equipment Other - Typically long test time EBTW 2005, Tallinn, Estonia Slide 5

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. EBTW 2005, Tallinn, Estonia Slide 6

EBTW05 EBTW05 � A quantity of cards could be � ‘no-boot’ � “Power On Self Test” (POST) failures. ICT PASS FT PASS OTHER Functional FAIL NO BOOT >Difficult to debug FAIL >Not really functional fails Debug � It seemed logical to add a stage between ICT & FT EBTW 2005, Tallinn, Estonia Slide 7

EBTW05 EBTW05 Where does MDT fit ? S T IN G E R F S + W o rkstatio n � Screen / Diagnose power-up failures eth ern et � Low cost 16 x rs232 cab les � basic equipment S erial /R S 232 � Test multiple units in parallel S erial /R S 232 EBTW 2005, Tallinn, Estonia Slide 8

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) EBTW 2005, Tallinn, Estonia Slide 9

EBTW05 EBTW05 Typical UUT � Brings up card in minimal mode (bypass P.O.S.T) � Provides ability to � Test all components � Target specific components EBTW 2005, Tallinn, Estonia Slide 10

EBTW05 EBTW05 What the user sees EBTW 2005, Tallinn, Estonia Slide 11

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 EBTW 2005, Tallinn, Estonia Slide 12

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 - - Software supplied by vendor with their chipset Software supplied by vendor with their chipset Vendor API Code � 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) EBTW 2005, Tallinn, Estonia Slide 13

EBTW05 EBTW05 Integration of MDT into an OS Operating System Application Code ( including User Interface) MDT Code Various higher level OS Code Blocks File System Utility Code Api wrapper Code (generic Frameworks) etc Component Component Component Vendor API 1 Vendor API 2 Vendor API 3 Integration of MDT into an OS. EBTW 2005, Tallinn, Estonia Slide 14

EBTW05 EBTW05 Code Structure The MDT code structure is designed to promote code re-use 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 EBTW 2005, Tallinn, Estonia Slide 15

EBTW05 EBTW05 Challenges .Were they addressed? � Less time to develop test solutions Development � Code Reuse � Need for test solution early in development life cycle PROTO � Code reuse Debug/ Repair � Need for test solution that is re-usable through Pre Production lifecycle stages � Need to cut test costs � Low cost Test equipment & concurrent Testing Production � Pre screen for FT � Make better use resources � better leverage from existing work done by component suppliers and internal software groups EBTW 2005, Tallinn, Estonia Slide 16

EBTW05 EBTW05 One Last Item � In order To enhance the benefits of MDT for a production production scenario it is integrated into a GTS (Generic Test System) scenario that provides: � An intuitive GUI � A data-logging framework. � Concurrent testing of multiple cells EBTW 2005, Tallinn, Estonia Slide 17

EBTW05 EBTW05 GUI & Data Collection C A R D x W r a p p e r M D T r u n n in g O S o n C a r d S c r ip t u n d e r O S C A R D x W r a p p e r M D T r u n n in g O S o n C a r d S c r ip t u n d e r O S G T S G U I F r a m e w o r k C A R D x W r a p p e r M D T r u n n in g O S o n C a r d S c r ip t u n d e r O S D a ta b a s e EBTW 2005, Tallinn, Estonia Slide 18

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 EBTW 2005, Tallinn, Estonia Slide 19

EBTW05 EBTW05 � Questions ? � Questions ? EBTW 2005, Tallinn, Estonia Slide 20

EBTW05 EBTW05 � Backup Slides ! � Backup Slides ! EBTW 2005, Tallinn, Estonia Slide 21

Slide 22 EBTW 2005, Tallinn, Estonia EBTW05 EBTW05

Slide 23 EBTW 2005, Tallinn, Estonia EBTW05 EBTW05

Slide 24 EBTW 2005, Tallinn, Estonia EBTW05 EBTW05