In this guide 6 sections
An IoT unit passes through six steps: a released BOM, board assembly, firmware programming, device identity provisioning, functional test and packing. Each step should create a record tied to one serial number, so any field fault leads straight to its part lot, firmware build and test result.
The BOM and the build file set come first
Before any board is built, two things must be frozen together. One is the bill of materials. The other is the firmware image, often a signed binary, plus the test script. Mixing a new BOM with old firmware is a common source of strange field returns.
Give the set one revision label. Every build refers to it.
For a startup, this is usually the moment the product moves from a prototype folder to a released build. Treat it like one.
Assembly creates the first records
The contract manufacturer places components, runs reflow and inspects the board with AOI, and you should receive a board or panel ID for each unit. That ID is the thread. Everything else hangs from it.
Ask for the lot or date codes of the main chips, such as the radio module, the sensor and the power regulator. When one batch of radios misbehaves, those codes tell you exactly how many shipped units are affected. Keep them.
Keep these as data you can search, not as photos in a shared drive. A scanned traveler in a folder is no use at two in the morning when a customer reports a boot loop. A row in a table, keyed by serial, is.
- Board or panel ID per unit
- Date codes for the main ICs and the radio module
- AOI result and any rework note
- Revision of the BOM that was built
- Name of the line and the shift
Programming and provisioning are not the same thing
Programming puts firmware onto the microcontroller, usually through SWD, JTAG or a bootloader over UART. Provisioning gives that one unit its own identity. That identity may be a device certificate, a unique key, a MAC address block or a cloud registration.
Provisioning is where records matter most. Each certificate or key must be tied to a serial number once and only once, and a re-flashed board must never quietly receive a second identity. Block it.
Decide where the secrets live. A hardware secure element, such as a crypto chip, lets the factory inject keys without ever seeing them in plain form. Without one, private keys pass through a programming station laptop, and that laptop becomes part of your security story.
- Firmware build number written to the unit
- Serial number to certificate or key mapping
- MAC or IMEI range allocated
- Cloud registration result
- Operator or fixture that did the flashing
Functional test proves the unit works
A bed of nails fixture or a bench jig checks power rails, radio output, sensor readings and button presses. Each result is logged against the serial. Failing units go to a repair queue, never back into the pack.
Test limits should be written in the test script, with its own version. If a limit changes, the log must show which units were tested under which limit.
Run a final check that the unit can reach your cloud and report in. A board that passes every bench step but cannot connect to the broker is still a failed unit. Treat it so.
Pack, ship and keep the history searchable
Labels, cartons and shipping documents should carry the serial or a range. Record which serials went to which customer or distributor, because without that a recall becomes a guessing exercise across every box you sent.
Then check that a single query can answer a field complaint. Pick one shipped unit, and see whether you can pull its BOM revision, part lots, firmware, identity, test log and shipment in one place.
If that takes more than a few clicks, list the missing links and fix the one nearest the factory first. Early records are the hardest to recreate, so protect them first.
IoT build traceability sheet
Rows run down the page, one per record, and the columns are: step, record created, where it is stored, the serial it hangs from and who owns it. The rows run from the released BOM and firmware set to assembly IDs, date codes, flashing, identity provisioning, functional test, packing and shipment. A last row asks whether the whole chain can be queried from one serial number.
Open a blank worksheet to printQuestions owners ask
What is the difference between flashing and provisioning?
Flashing loads the firmware. Provisioning gives the individual unit its identity, such as a certificate, a key or a cloud registration. Flashing is the same for every unit, but provisioning is unique to each.
Who should do provisioning, the factory or us?
Either can. Doing it at the factory saves time but means trusting its process with your secrets. A secure element and a signed provisioning log reduce that risk.
Which records do I need to keep for a small batch?
At least the serial, BOM revision, firmware build, test result and shipment. Add part lot codes for the radio and power parts. Records are cheap to keep and costly to rebuild later. Store them as rows you can filter, and keep a copy off the laptop of whoever runs the line.
Do I need software for this at the prototype stage?
A spreadsheet is fine for a handful of units. Move to proper records when you build in batches or sell to customers who ask for traceability.