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 ICT failures consistently point to “Shorts under U12,” the engineering team can investigate the stencil design or the reflow 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.

Final Checklist: Repair and CAPA Discipline

Stage / Action	Goal / Verification Point	Key Performance Indicator (KPI)
Logging	Every board failure ideally auto-generates a ticket with SN, Defect Code, and Process Evidence (e.g., 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 MES.
MRB	Final disposition (Scrap/Rework/Use-as-is) is decided by the MRB team based on risk and CoPQ.	Disposition Mix (Scrap rate trend); CoPQ (Cost of Poor Quality) total.
CAPA Loop	Recurring or critical failures prompt the opening of a CAPA with a measurable Effectiveness Metric.	Top Pareto defect frequency; CAPA Closure Rate with verified effectiveness.