In this guide 6 sections
Give every unit a serial number and record against it the board revision, firmware build, component lots and final test result. When a fault appears in the field, one query on that record shows which units share the suspect part or build, so you act on exactly those.
A serial number must point to a record
A serial number alone tells you nothing. It becomes useful when it is the key to a record. That record holds the board revision, the firmware build, the lot of each critical component and the result of the final test.
Start with what you can already name. The PCB carries a revision letter near the connector. The bootloader prints a version string on the debug console. The microcontroller, flash chip and power regulator each arrive on reels whose labels show a lot and date code.
- Board revision, plus any rework or jumper wire changes
- Firmware build identifier and the commit it was built from
- Bootloader version, which often differs from the application image
- Lot and date code of the controller, memory and power parts
- Calibration file or configuration written at end of line
Capture each fact where it is first known
Data typed in later is data typed wrong. Scan the reel label when the feeder is loaded on the pick and place machine. Scan the board barcode at the programming station, where the flashing tool reports the image it wrote and its checksum.
Scan again at functional test. The jig already produces a log file, so store it against the serial instead of leaving it on a laptop under the bench. A recorded current draw and radio output reading beats a tick in a box.
Keep every scan quick. Operators skip any step that costs more than a few seconds. Where a barcode reader can fill three fields at once, use it.
Record what happens after the unit leaves
Units do not stay as shipped. An over the air update, a technician reflashing a unit on site and a returned unit repaired and sent back all change the truth. If those events never reach the serial’s history, the data is stale within a quarter.
Each change should log the serial, the old build, the new build, the time and who or what pushed it. Failed updates count too. A unit stuck on the previous build after a bad download is exactly the unit support will be asked about.
- Update result, success or failure, with the error code
- Reflash by a named technician and the reason given
- Repair events with replaced parts and their lots
- Status for returned, refurbished and scrapped units
Scope a fault or recall from the lot upwards
Support reports random reboots. Engineering suspects a brown out when the motor starts, tied to one regulator lot. Without traceability you recall a year of production. With it, you query the lot, get a list of serials and filter out units already running the fixed build.
The list then splits into groups. Units in your warehouse are held. Units at distributors are found from dispatch records. Units with customers get a notice or an update.
Each group needs a different action. Narrow scope saves money. It also shows a key customer or an auditor exactly how you reached the list, and which units were left out and why.
Prove it on one product line first
Do not trace the whole company on day one. Pick the product with the most field complaints. Write down the five facts you wished you had during the last fault, and add only those to the line.
Then run a drill. It takes an hour. Choose a component lot at random and time how long it takes to list every serial that contains it. If the answer is days, fix that before adding fields. Run the drill with your production lead this Friday, and keep the stopwatch result.
Serial record and recall drill sheet
One page with a row per unit and columns for serial, board revision, firmware build, bootloader, controller lot, memory lot, test jig log reference, ship date and customer. The lower half sets out the drill steps: pick a lot, list its serials, mark the build each runs and sort units into held, at distributor and with customer.
Open a blank worksheet to printQuestions owners ask
Can a spreadsheet hold this data?
A spreadsheet copes with a few hundred units a year. Beyond that, lot to serial queries slow down and rows get overwritten. Once several people edit at once, a database with proper keys is safer.
How do I trace units shipped before I kept records?
Usually you cannot do it fully, and it is better to say so. Bracket likely units by build dates, work order numbers and the firmware release log. Start proper records with the next batch and mark older units as estimated. A recall notice can then name a build date range instead of a guess.
Should the serial number encode the firmware version?
No. Firmware changes after shipment, so the code would go out of date. Keep the serial plain and unique, and store the build in the linked record. Then an update only changes one row, and the label on the unit stays true.
Which components need lot tracking?
Start with parts that cause field faults or safety concerns: controllers, memory, power parts, batteries and radio modules. Bulk passives can be tracked by reel batch if a fault points to them.