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 Manufacturing Execution System (MES) is so valuable.

The Anatomy of a Repair Ticket

When a board fails a test (whether ICT, Boundary Scan, or FCT), the test station naturally should generate a digital Repair Ticket linked to the board’s unique serial number in the MES. A well-constructed repair ticket helps clarify the next steps for the repair technician.

A standard repair ticket typically contains the following elements:

1. 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.”
2. 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”).
3. 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.
4. 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

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)

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 the reflow 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

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 Root Cause Analysis. Thoughtfully addressing failures is a key part of an effective manufacturing strategy.

---

Recap: Data Logging & Repair Ticket Procedures

Parameter	Requirement	Value / Condition	Action
Failure Mode	Specify measured vs. expected value with tolerance.	e.g., “3.1V, expected 5.0V +/- 0.1V”	Log in Repair Ticket.
Diagnostic Data	Specify failing nets and component reference designators.	e.g., “Short between Net A and Net B at R12, C4”	Log in Repair Ticket.
Repair Action	Document replaced component and corrective action.	e.g., “Replaced U4. Cleared solder bridge.”	Log in Repair Ticket.
Verification	Re-test at the originating test station.	Same station that recorded the initial failure.	Mandatory post-repair.
Queue Clearance	Assess and clear failed boards from repair queue.	Within 48 hours.	Escalate to Engineering if unresolved.