In this guide 6 sections
An embedded device record is a linked set of entries for one product: hardware revisions, firmware builds, test fixture and script versions, component choices and certification files. Each stage from prototype to production adds entries, and each entry names the version of its neighbours, so any shipped unit can be rebuilt on paper.
One product, many linked records
Think of the device record as a spine with branches. The spine is the product and its revision history. The branches are boards, firmware images, fixtures and approvals that each carry their own version.
The point is the links. A firmware build means little until it says which board revision it was tested on and which bootloader it expects.
Without links, a field question costs a day of hunting through email, shared drives and the memory of whoever built the first board.
Hardware revisions and what changed
Each board revision needs a number, a schematic and layout snapshot, a BOM and a short change note. Say why a rev B exists, such as a swapped regulator after a supply shortage or a moved antenna keep-out.
Record assembly details too. Which fab, which stencil, which reflow profile and which ICs were substituted matter when a batch behaves differently.
Keep the Gerber files and pick and place file as attachments. Rebuilding a prototype from memory is how old bugs return.
- Schematic and layout snapshot per revision
- BOM with approved alternates
- Reason for the change
- Gerber and assembly files
- First batch size and build date
Firmware builds tied to hardware
Every firmware image gets a version, a commit hash, a build date and the compiler or toolchain version. Record the bootloader, the configuration blob and any signing key identifier, but never the key itself.
Then state compatibility. Firmware 2.4 runs on rev B and C, not rev A. That one line prevents a technician flashing the wrong image onto a batch.
Production firmware differs from the debug build. Say so.
- Version, commit hash and build date
- Toolchain and bootloader version
- Compatible hardware revisions
- Known issues and release notes
- Checksum of the image file
Test fixtures, scripts and certification files
A bed-of-nails fixture, a programming jig and a test script are all versioned items. If a limit changes in the script, units tested before and after the change need to be told apart.
Certification files belong in the same record. Keep the test reports, the declared configuration, the labelling artwork and the date, so a design change can be judged against what was approved.
A change to an antenna or a power stage may need a new radiated emissions test. The record shows which approval it touches.
Keep the record alive after launch
At production start, add serial ranges and link each serial to the hardware revision and firmware it shipped with. Field updates then append to the unit’s history instead of replacing it.
Review the record at each revision gate: prototype, pilot build, release and any later engineering change. Ask one question each time, which is whether a stranger could rebuild this unit from the record alone.
Try that question on your current product this week. Note the gaps.
Device record template
The template fits on a single sheet and has four blocks. Hardware lists revision, change reason, BOM and fab files. Firmware lists version, hash, toolchain and compatible revisions. Test lists fixture, script version and limits. Approvals lists certificates, report dates and labelling artwork, with a column linking each item to its neighbour.
Open a blank worksheet to printQuestions owners ask
Is this the same as a bill of materials?
No. A BOM is one part of it. The device record also carries firmware, test setups, approvals and serial ranges, and links them by version.
Who owns the device record?
Usually the embedded team lead, with input from hardware, test and quality. One named owner keeps entries current.
When should we start it?
At the first prototype. Adding history later means guessing, and guesses are hard to defend to a certification body or a customer.
Where should the files live?
Source code stays in version control, and large files such as Gerbers and reports can sit in storage. The record holds the links and version numbers that tie them together.