Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Practical Digitalization in Electronics Manufacturing
Similar to Practical Digitalization in Electronics Manufacturing (20)
Recently uploaded
Recently uploaded (20)
Practical Digitalization in Electronics Manufacturing
- 1. Practical Digitalization in Electronics Manufacturing Application of Test Data for Business Improvement Tom Arne Danielsen Area Sales Manager tad@virinco.com
- 2. • Digitalization Challenges • Traditional Quality Management Approaches • High Level Approach • Analyzing Data – Examples • Yield • Top failures • Retests • Limits • Comparisons
- 3. Digitalization and Profit 101 Profit Margin Investment Cost Market Pressure Time Money t=Past t=Profit Opportunity t=Loss Reduction or t=Bankruptcy delay Operational Improvements
- 6. • Multiple Data Formats -> Uniform Data • Difficult to compare and correlate • No automation of data collection • Problems not discovered when they happen • Early intervention gets impossible • Globally Distributed Data Sources • Networking topologies, router configurations, firewalls • Limited or no data from Subcontractors • Providing customers with access to data • Analysis Paralysis • Analysis addressing the wrong problems • Do you know your True First Pass Yield? Homegrown solutions • Poor performance, high maintenance cost • Non-core business Challenges Using Test Data
- 7. Cost of Analytics Source: forbes.com
- 8. Statistical Process Control • SPC Assumption: Elimination of common cause variation • Data characteristics • Highly dynamic – components, 3rd party vendors, number of steps, operators, test machines, instrumentation, fixtures, processes etc • 100s of test sequences • 1000s of test steps • Example from Aidon (Petri Ounila) • Batch size 10000 units • 357 total number of components • 137 different types of components • 37 component changes -> change every 280th unit • Process, operator, instrumentation changes A change per every 10th product, or less
- 9. WECO - Western Electric Rules Traditional SPC analysis • Proactive detection of ‘out of control’ processes
- 10. Origin of Fault? KPI Monitoring PCB Test In- Circuit Test Module Test System Test Deployment Traditional methods Selecting KPIs
- 11. Deployment Profit Loss from Failures Found 1x 10x 100x 1.000x >10.000x PCB Test In- Circuit Test Module Test System Test 10X Cost Rule
- 12. Limited dimensions/meta data due to capabilities and cost Assumptions of root cause Only known-unknown Limited by Data available Analysis Paralysis by Low Level Approach Lack of Real-Time visibility Lack of Data Availability Wrong Improvements Long Cycle Time Not Lean - Significant Waste What? Why? Improvement Contstraints
- 13. Following Best-Practices Automated Collection Integrated Repair Data Problems based on insight Don’t actively search in data True 1st Pass Yield Yield, Pareto, CPK Numerical Analysis 8D Root-Cause Module Global Data Acquisition Real-Time Dashboards Trigger-Automation Alarms High-Impact Improvement with good cost/benefit ratio
- 14. Architecture TCP/IP converter WatsStandardTextFormat WATS Client Reporting and Analysis Offline support WatsStandardXMLFormat Application in cloud or on-premise External tools and apps
- 15. Dashboards What? • Distributed globally and locally for Real-Time Visualization
- 16. Yield Reports • Overview by pn, revision, site, process, period etc What?
- 17. What is failing the most? • Pareto shows top 10 failures Why?
- 18. # of Retests • Are you shipping products that has failed a test multiple times? Why?
- 19. Process Capability Analysis • Are your limits correct? • FPY 99-100%, tests not failing Why?
- 20. Numerical analysis • Compare different measurements Why?
- 21. • Assign issues • Team Collaboration 8D Root Cause Analysis Why?
- 22. Repair/RMA Module Why? • A failed test is a symptom of a problem • Repair Data adds important context • Historical knowledge base to guide repair operator
- 23. Repair/RMA Module • A failed test is a symptom of a problem • Repair Data adds important context • Historical knowledge base to guide repair operator Why?
- 24. Gage R&R • How much of the variation comes from the measurement system Why?
- 25. Data Export Why?
- 26. DEMO
- 28. Western Electric Rules Traditional SPC analysis • Statistical uncertainty defined by WER, 1 false alarm per 91,75 oberservations – 110 false alarms per 10k • Useless for realtime analysis of test data
- 29. Integrating with the Enterprise Easy to use Easy to implement Easy to integrate
- 30. Test Data Management MES - no drilldown to test details - limited connection to test system - lacks multisite SPC - bottom up approach - choose KPIs based on product performance - no repair Dashboard - no connection to test systems - no drilldown to details - no repair Data lakes - no understanding of test data, repair - spurious correlations Test Data Management
Editor's Notes
- There are two broad reasons why companies have digitalization initiatives. One of them are the possibility for new business models, companies such as Uber, Google etc who build business cases around servicing people, the Business to consumer side. The Business 2 Business side mainly look at how to enable companies to improve efficiency and profitability <click> a company excelling in business intelligence can expect to experience increased profit margins <click> largely due to operational improvements they do, either internally or towards the market, and is a source of competitive advantage. <click> In the longer run, more and more companies will go through the same journey, and the market pressure will reduce the profit margins again, as competitive advangate is a measure relative to the other players in the industry. <click> If we assume that the time after today is where our profit opportunity lies <click> we also have to be mindful of the investment cost needed. <click> and the fact that there is a delay between this and the peak return. <click> this initial investment can come at any time in the future, and if it happens too late the profit opportunity has passed, and you are potentially fighting for survival.
- There are several dimensions that affects the profit margins of a company, in the broader sense the continuum where the optimal value is found is determined by the quality of the products, the efficiency and the cost of operations. Unless you are able to measure these the outlook for short term profit gain and long term competitive advantage are not good.
- Because at the end, what you would like to be able to achieve using your insight into these dimensions is to implement the improvements that has the highest possible return, for the least available effort. There is always going to be improvements to be made, and it is critical that one is able to distinguish the noise from the really valuable ones.
- https://www.forbes.com/sites/gilpress/2016/03/23/data-preparation-most-time-consuming-least-enjoyable-data-science-task-survey-says/#17530a7c6f63
- Many solution providers in this space base their technology on Statistical Process Control, a technique dating back the 1920s. One of the fundamental assumptions of this to work is that you are able to remove what is called common cause variations from the manufacturing process. <click> In a modern electronical product you have a massive amount of variables compared to the 20s, like firmware, component changes and revisions and so forth. <click> An example we have from Aidon, who design and manufacture smart meters, gives that for one of their batches containing 10000 units they have a change in their process <click> every 10th product or so. This is representative to a change in these common cause variation factors that SPC relies on.
- In SPC you have rules such as WER from the 50s defining alarms for out of control processes. One problem is the dynamics of manufacturing itself, another one is that it on average gives a false alarm per 91,75 observation. If you have 10.000 products per year, tested over 5 different processes each with 25 different measurements this will flood you with alarms, totally undermining the purpose of an alarming system.
- So what is done is that one makes assumptions on what is important, and measure KPIs, <click> Often late in the process, like a system level test. The origin of the product however could easily be upstream, from a batch of PCBs. In some cases you don’t even measure on all units due to the operational limitations, but resort to sampling where you measure in certain intervals. <click> So a poor batch of PCBs that was allowed to pass means that you need to move the full system to repair rather than just the PCB.
- You’re probably familiar with the 10x rule, and according to this the cost in this example would be 100x what it could have been had the issue been detected real-time, thus contributing to significant waste of resources. Takata Airbags is a good example from recent time, having to declare bankrupcy because faulty products was shipped to the market.
- If we map this onto Continuous Improvement Initiatives, we’ve illustrated it with the Six Sigma DMAIC cycle but it can be anything intended to drive general improvements - traditional approaches contains limitations in every step when it comes to understanding _what_ is really going on, and _why_ this is happening. At the end of the day data science is about answering these two question categories. <Click> First of, many approach the task from pre-defined KPIs based on just a few measures. You ignore challenges upstream in the process, you ignore parameters outside of your assumed KPIs, and you further make assumptions of stability in parameters within the manufacturing process that is in fact dynamic. At the very best you are able to find answers to your known-unknowns, disregarding the unknown boilerplate issues. If you look at the different dimensions one takes into consideration in a Fishbein analysis, often you fail to account for all except the material specific one. <Click> The data capture then follow the limitations sat forward by the definition, it is limited to your KPIs and the meta-data relevant to it. Not necessarily that you don’t record more data, but your system is not capable of processing it. Should you identify that different data is needed, this is often not available from a practical point of view, since collecting it and correlating it is a huge effort. <Click> The analysis part is then inhibited by this, either you can’t find causalities on identified problems or you identify incorrect correlations. <Click> You then go on to implement improvements that don’t have good return on, or at least not a good compare on when it comes to prioritizing, leaving much waste that you are not even aware of. The manual operations of collecting the data and interpreting often gives cycle times of up to a month, when in some cases you should be looking to improve within hours. <Click> Finally in the control and monitoring stage you don’t have timely availability of the data to control your improvements, and the lack of necessary meta-data also hinders you to feed back valuable new problem definitions.
- These constraints are what we remove with skyWATS, and how our customers are able to continuously progress towards operational excellence. <Click> And you need the complete story to get here. Our philosophy is that actively looking for problems in your data is not sustainable, as a rule of thumb you need to be presented the indicators as they happen. <Click> The data we collect then contains all the necessary meta-data to avoid limiting your root-cause analytics. The collection of data is automated, and happens in real-time, and we also collect repair data as this has significant relevance when moving further <click> From an analytics point of view we have a top-down approach, where True 1st Pass Yield most often indicates infant problems. We have built in statistical capabilities, similar to SPC tools, and we have a Root-Cause module where the team can collaborate to get to the bottom. <Click> The result is that you get the possibility to arrive at improvements that follows the principles of 9 Suares, if you are familiar with it, an optimized mix of return vs effort. <Click> In the feedback-loop and control part we have Real-Time Dashboards that report data from all of your factories, these dashboards would also be implemented at local levels to visualize their improvement processes or KPIs. In regards to the article you read before contacting us in December, these Dashboards is what is preventing problems sneaking up on you. Befor we move forward I’ll give you a specific example of early intervention that a customer recently told us. On a Monday morning, from HQ in Europe, they saw that the yield on one of their China factories dropped, both visible on their dashboards, plus that it triggered an alarm. They were quickly able to dig down and find that it was one ATE that contributed to this. The failure pareto told them what measurement was the origin of this, and they could go further into numerical analysis. Within 20 minutes of identifying the problem they had learned that there was a requirement of their Yokagawa power instrument for a 3 hour warm up time, something that no one had implemented a routine for or even knew, and that they were able to improve on immediately. The problem was that this one specific system had been powered down the day before that was a Sunday. Now, this did not directly represent a quality issue of the product, but the boards failing would have to be re-tested, adding waste to the process, plus it might have also been sent to repair that would have increased the probability of new introduced failures.
- The way we collect data is that clients are installed where the test data is, this can either be on the ATE itself, or a local database if this has been implemented. <4 x Click> We have some plug and play support and existing APIs that can achieve this, but the user can also modify their file formats to a standard we have, WATSStandardXML or Text, or a converter can be made that takes your existing data. This means we can integrate your historical data easily. <click> The data is moved to a cloud or on-premise server that the reporting and analytics application connects to. You can export data directly through XML or spreadsheets from here, <click> And there is also a Rest API that you can pull data from the server with. We use this API in our app for mobile phones.
- As mentioned, our process flow is a top-down one, and most often start with real-time dashboards. These will typically be either global shared dashboard for specific business units, or private ones that gives you the specific view you need. These KPI’s are calculated on the server in real-time, based on the continuous incoming flow of test reports. <click> Often these dashboards are displayed on monitors in the public area, enhancing the perception of quality being a shared responsibility.
- The more detailed views, what we call the reporting section often starts with first pass yield, and you can slice these across multiple dimensions such as product, revision, site etc, to look for outliers in performance.
- One step deeper we would typically look at the most frequent failures. This don’t have to be on one specific product, it can also be the most frequent failures at a product family, or factory for that matter.
- Looking at the overall yield statistics lets you see in what run certain products passed. In this case we see that 160+ products passed the second test, while there were actually some products that passed in the 11th run. Not necessarily something you want to ship to customers by default just because you now have a green light.
- You can also look at process capability analysis to see how your measurements are performing compared to the test limits.
- Digging further down we can do numerical analysis, look at correlations between measurements and more advanced calculations
- As mentioned, we consider capturing repair data instrumental for a quality management solution, as this will provide context data to why a test has failed. Many companies captures some repair data, but it lives only in the MES system. We can either capture it directly in WATS through a web application, or we can interface the MES system.
- One of the benefits of doing it in WATS is that we can link the repair to a specific test report, thus increasing the data value, and giving you full traceability of the product history.
- Klikk videre
- We’re also very flexible when it comes to integration in the Enterprise system.
- Without going into