|WATS cloud Availability - User Level:||Operator, Analyzer, Manager|
When a Unit fails a test and log the UUT report, it tells the symptom of the failure (e.g. failed in the 5 volt internal measurement). The next step of investigation is the repair or rework operation. With the Repair functionality operators can launch a web based reporting tool that allows them to scan the unit’s serial number and WATS will automatically retrieve the failed UUT report and display the failed test(s).
Further, the operator can enter (from a predefined code list) the type of Failure/repair/rework on the unit (e.g. Solder balls), reference to a component, comment and attach an image of the failure (e.g. picture of a broken connector). By combining test results with repair data, WATS can provide advanced analysis and traceability.
Performing a repair operation, using the Operator Interface
To perform a repair, open the Operator Interface, and type or scan a serial number and click apply. Then click the repair icon in the menu. This will bring up the repair interface where you will be taken through three steps.
1. Select repair operation
If you have multiple repair operation types the first step is to choose the type you want from a dropdown list. If there is only one present, this step will be skipped.
2. Identify UUT report
The next step is bind the repair(UUR) to a test report(UUT). You will see a list of available UUT. Select the UUT you want the repair to bind to, and click Confirm selected UUT. If no UUT is available for the scanned serial number, you will have the option to bind the repair to a test operation, part number and revision, provided that the repair operation has UUT binding set to optional or never.
3. Add failures and replace sub units.
Once the UUT is identified, you will be able to add failures. You can choose a failed step from the UUT to identify the failure to. By default the step that caused the UUT to fail will be selected. Choose your repair category and code from the dropdown list, and type in or choose component reference (depending on your BOM-list binding or CompRef mask).
Click the green confirm-button to save your changes.
When you are done adding repair codes/failures, click Submit report to finish the repair operation and save the report. Submitting the report will take you to the Unit history view, where you can see all UUTs and UURs related to this serial number.,
What is best practice in regards to performing a repair that fails?
1. We run a product through our tester, which fails.
2. We initiate a repair operation.
3. We bind the UUR to the latest failed test report UUT.
4. We suspect that a component is defective and replace it.
5. We run it through the tester again (UUR report is still open)
6. The tester lets us know that it still failed at the same step, and we submit the UUR report as an own made code "Repair failed" but still document the Comp ref.
7. The product is still not passed but we still have repair history on the serial number, and in the future the data shows that swapping X component to fix this step resulted in "Repair failed" count X times.
How would you deal with repairs that are difficult to problem solve and result in not being able to fix it. Above is our idea of how we would implement the repair module in our processes. The "Code" list is full of root causes, but sometimes this doesn't get solved, but you still made a swap to a product that you want to maintain repair history on.
It is hard to determine whether a repair did fix the issue or not (as you describe). As example, if you repair/replace first component, test the unit again and it fails, then repair/replace a second component, test the unit and it passes - can you then be certain that the 1st component did not effect the result? It may be that just replacing the second component also had not Passed the unit.
I think your suggestion is one way of doing it. Another "best practice" is to submit the first repair with "real" repair code, test the unit (fails), then submit a second repair report. Then, in repair analysis, you can use the Run filter to get statistics of the "last" repair reports submitted. This may give you an idea at least of the "final" repairs.
Please sign in to leave a comment.