5.5 Data Logging & Repair Tickets
In a high-volume manufacturing environment, conducting tests is only part of the process; managing the data those tests generate is equally important. A test station that simply flashes a green “PASS” or a red “FAIL” light does not provide enough insight. When a complex circuit board fails an electrical test, the rework technician benefits from precise, actionable information to repair it efficiently. Furthermore, engineering teams need aggregated historical data to identify systemic process drifts early. This is why a standardized approach to Data Logging and Repair Ticketing within a
The Anatomy of a Repair Ticket
Section titled “The Anatomy of a Repair Ticket”When a board fails a test (whether ICT,
A standard repair ticket typically contains the following elements:
- The Exact Failure Mode: Rather than “Board Failed
FCT ,” the ticket should state precisely what happened, such as “Analog Voltage Regulator U4 output measured 3.1V, expected 5.0V +/- 0.1V.” - Diagnostic Coordinates: For structural tests (like ICT or
JTAG ), pinpointing the exact failing nets and reference designators is helpful (e.g., “Short detected between Net A and Net B near components R12 and C4”). - Historical Context: Noting if this specific board has failed this test before is important. If a board is caught in a loop (failing, being repaired, and failing again), the MES should highlight this so an engineer can offer guidance.
- Relevant Log Snippets: For functional tests, attaching the last few lines of the serial console output or the specific error code returned by the product’s firmware provides excellent context.
The Technician’s Workflow: The Repair Loop
Section titled “The Technician’s Workflow: The Repair Loop”The repair process works best as a controlled, closed loop. A board that fails a test should complete a defined verification cycle rather than returning directly to the standard flow after a touch-up.
| Process Step | Expected Outcome |
|---|---|
| 1. Scan and Review | The technician scans the board’s barcode to access the digital Repair Ticket, confirming they are addressing the correct, current failure. |
| 2. Perform the Repair | The technician identifies the physical defect and corrects it (e.g., replaces a faulty IC or addresses a solder bridge). |
| 3. Document the Action | The technician logs exactly what component was replaced and the action taken (e.g., “Replaced U4. Cleared solder bridge on pins 1-2”). This data feeds into yield analysis. |
| 4. Return to Origin | The repaired board is routed back to the same test station that initially flagged the failure, ensuring a complete re-verification. |
Utilizing Test Data for Root Cause Analysis (RCA)
Section titled “Utilizing Test Data for Root Cause Analysis (RCA)”Test data serves as a valuable diagnostic tool for the entire production line. Aggregating test data helps drive continuous improvement rather than just guiding the repair of individual boards.
- Identifying Trends: The Quality Engineering team can review a Pareto chart of failure modes regularly. If a significant percentage of
In-Circuit Testing (ICT) failures consistently point to “Shorts under U12,” the engineering team can investigate the stencil design or thereflow soldering profile for that specific component. - Component Tracking: By logging the exact reference designators that are frequently replaced, potential issues with component batches from suppliers can be identified early.
- Test Station Health: If one test station is failing 15% of boards for a specific parameter while another station testing the same product is failing 2%, it may indicate a fixture maintenance issue or a calibration drift, rather than a product defect.
The “No Bonepile” Target
Section titled “The “No Bonepile” Target”A “bonepile” refers to a stack of failed, un-repaired boards accumulating in the factory. These stacks tie up capital and can obscure manufacturing issues. A common manufacturing target is to ensure failed boards are assessed and cleared from the repair queue promptly, ideally within a 48-hour window.
If a board cannot be repaired within an expected timeframe due to a complex schematic or intermittent failure mode, it is best escalated to the engineering team for a formal
Final Checkout: Data logging & repair tickets
Section titled “Final Checkout: Data logging & repair tickets”| Stage / Action | Goal / Verification Point | |
|---|---|---|
| Logging | Every board failure ideally auto-generates a ticket with SN, Defect Code, and Process Evidence (e.g., Automated Optical Inspection (AOI) image). | Aging Tickets (monitoring closure within the target window). |
| Rework | Rework technicians follow established Work Instructions (WIs) and log part changes and heat cycles. | MTTR (Mean Time To Repair) by defect code; Repeat-Fail Rate for the same fault. |
| Verification | Repaired boards successfully pass the failing test step again before proceeding. | Retest completion rate logged in the |
| MRB | Final disposition (Scrap/Rework/Use-as-is) is decided by the | Disposition Mix (Scrap rate trend); CoPQ (Cost of Poor Quality) total. |
| CAPA Loop | Recurring or critical failures prompt the opening of a | Top Pareto defect frequency; CAPA Closure Rate with verified effectiveness. |