How to Define PCBA Traceability Requirements
Start PCBA traceability requirements with the questions you may need to answer after shipment. Which units have a particular firmware version? Which boards received a replacement component? Was a failed unit retested after repair? To answer these questions, the board identifier must link to the relevant production records.
Agree on the level of detail before requesting a quotation. Batch records, individual-board histories and component-lot tracking require different data collection steps. A serial number alone does not establish which manufacturing lot each fitted part came from.
Decide which records need to identify individual boards
A batch record may be enough to identify the assembly revision, approved BOM and shipment. Unit-level records are useful when boards have different firmware configurations, calibration values, test results or repair histories. Choose the level needed for fault investigations and customer requirements, then confirm how production will collect those records.
For component-lot traceability, identify the critical lines and the required link from incoming material to the assembled units. If reels are changed mid-batch, the process needs a way to capture that boundary. A purchase order listing two lots does not identify which unit received which one.
Assign an identity before the operations you need to track
Specify who allocates identifiers, their format, when they are assigned and whether they must be unique within a batch, product line or across all products. Decide whether an identifier refers to a panel position, individual PCBA or finished product. Where separate identifiers are used, keep them linked through depanelization and final assembly.
Define what happens to allocated numbers when a board is scrapped or a label is damaged. Replacement labels must not create a second physical unit with the same identity. A firmware identifier and a printed label should be checked for agreement when both represent the product serial number.
Define the fields and how to retrieve them
The fields below provide a starting point. For each additional field, specify where the data comes from and who records it.
| Field group | Example field names | Why it matters |
|---|---|---|
| Identity | unit_id, work_order, panel_position | Connect the physical board to the right record. |
| Configuration | assembly_revision, variant, bom_revision | Distinguish what was authorized to be built. |
| Programming | firmware_version, image_hash, programming_result | Identify the released image and recorded operation. |
| Test event | test_revision, station_id, timestamp_utc, result | Interpret the result against the correct procedure. |
| Exception | failure_code, repair_record, approval_reference | Retain the reason and authority for later action. |
| Delivery | shipment_id, final_disposition | Locate affected units after release. |
A CSV can work for a small batch if identifiers, field definitions and update rules are controlled. Whatever storage system you use, check that the station records the correct board identifier. Test retrieval with a sample unit before accepting the format.
Retain failed tests, repairs and retest results
Store separate attempts with their time, operation and outcome. If a board fails, is repaired and then passes, the final record should preserve all three events and their relationship. Overwriting the first failure removes information needed to distinguish a product fault from a station or contact problem.
Tool logs can contribute evidence, but their fields need interpretation. SEGGER’s Flasher documentation describes programming-cycle logs and serial-number configuration. A cycle reference is not necessarily the same as the finished product’s label; map and verify that relationship in the station procedure.
Link engineering deviations to the approval record and the affected units or batches. An email copied into a comments field can be hard to interpret months later, especially if it does not identify the units concerned. Define those units through the engineering change-control process.
Make retention and handover part of the order
Agree who owns the records, who can access them, how corrections are recorded and how long they will be retained. Specify the export format and whether it includes raw measurements or only pass/fail summaries. Define how a customer can request the underlying evidence after delivery.
Do not place credentials, private keys or unnecessary personal information in general production logs. Where sensitive per-unit provisioning is required, separate secret handling from the non-secret evidence that the operation was completed.
Before shipment, select sample board identifiers and retrieve their configuration, test and final disposition records. Resolve missing links and duplicate identifiers before accepting the batch data. Run this check for low-volume builds too; a small batch still needs records that can be retrieved and understood.
Cover image: AI-generated editorial illustration, not a production record or an acceptance reference.
