In digital manufacturing, quality assurance across the assembly line is imperative. Identifying errors, slowdowns and potential failures before they occur rather than after they are detected can help companies be more proactive and improve productivity. The goal of the solution guide presented here is to predict failures in manufacturing pipelines (assembly lines). This is done by leveraging test systems already in place and failure data, specifically looking at returns and functional failures at the end of assembly line. By combining these with domain knowledge and root cause analysis within a modular design that encapsulates main processing steps, we provide a generic advanced analytics solution that uses machine learning to predict failures before they happen. Early prediction of future failures allows for less expensive repairs or even discarding, which are usually more cost efficient than going through recall and warranty cost.

The snapshot below shows an example PowerBI dashboard that gives insights into the manufacturing assembly lines that are monitored.

Assembly line scenario: For a computer mother board assembly line (Figure 2), at ALS 3 (ALS_03) the solder paste is applied on the empty board, and then a regular test is applied to check if the paste droplets are not too big or not too small and if they are at the center or each pad. Boards than pass the existing, already in place regular test move to next ALS-s, eventually the electronic circuits are placed on the board and then connected to the board pads by melting the solder droplets in an oven, and in the end of ALS 5 (ALS_05), a final electronic functional check is done before the board is shipped to client OEM PC manufacturer. Some of the failures discovered at ALS_05 are due to defective solder paste application performed in ALS_03, even if the board passed the regular ALS_03 test. We can use ML to predict solder related failures right after the solder paste is applied in ALS_03, but before the expensive electronic components like microprocessors and other integrated circuits are added to the board in ALS_05. Rewashing a board with functional defect yielding solder paste application that passed the regular QA test at ALS_01 may cost cents, while scrapping a defective board at ALS_05 after the processor and all other components are applied may cost hundreds of dollars.

OEMs who use contract manufacturers (Apple-Foxconn, MSFT-Jabil), and want to minimize post sale service and warranty costs: Use ML to build models that use test/shop floor data (that belongs to OEM and or CMs) to predict, before shipping, field return and repairs that may happen months or years after device is shipped. This enables predicting future failures while the device is still in the early manufacturing line stages or is already assembled but is not yet shipped, so that fixing or even discarding it may be cheaper than going through recall and warranty costs.

This solution package contains materials to help both technical and business audiences understand our Quality Assurance solution for manufacturing built on the Cortana Intelligence Suite.

In this repository you will find a folder labeled Solution Overview for Business Audiences which contains a presentation covering this solution and benefits of using the Cortana Intelligence Suite

For more information on how to tailor Cortana Intelligence to your needs connect with one of our partners.

See the Manual Deployment Guide folder for a full set of instructions on how to put together and deploy a Quality Assurance solution using the Cortana Intelligence Suite. For technical problems or questions about deploying this solution, please post in the issues tab of the repository.

A playbook for approaching predictive maintenance problems, which can be considered to include use cases such as that discussed within this solution, is published here and includes detail on how to prepare data sources, create features, and set up a machine learning model. There is also a modelling guide published in the format of a Jupyter notebook written in R here and some details on how to think about evaluating predictive maintenance models here.