Revisions & change control
PCB Revision vs Assembly Revision: When Should Each One Change?
Nine changes over two years, three of which need new bare boards. A worked progression, a decision table, the edge cases, and the one rule that settles most of them.
A board goes through nine changes in two years. Three of them need new bare PCBs. Six do not. If all nine bump the same number, you order new boards you do not need; if none of them does, you cannot tell a fitted board from a bare one.
This is why most teams end up with two revision identities on the same hardware, and why it is worth deciding deliberately rather than discovering it.
The two things being identified
PCB revision identifies the bare board — copper, footprints, drill, outline, stackup. It is what the fabricator builds.
Assembly revision identifies the populated board — which parts are fitted onto which bare board. It is what the assembler builds, and it is what ships.
The relationship is one-to-many: one PCB revision normally carries several assembly revisions over its life.
A common notation writes them together: Rev C-2 means PCB revision C, assembly revision 2. Other teams use C.2, or keep two separate fields. The notation matters much less than being consistent.
A worked progression
The fictional ORION CONTROL UNIT Main Control Board, over two years.
| # | What happened | PCB rev | Asm rev | New bare boards? |
|---|---|---|---|---|
| 1 | First prototype build | A | 1 | yes |
| 2 | C12–C18 changed to X7R after thermal testing | A | 2 | no |
| 3 | R33 value corrected, 10k → 4k7 | A | 3 | no |
| 4 | Ground plane split corrected; J1 moved 2 mm | B | 1 | yes |
| 5 | Second source approved for R22 | B | 2 | no |
| 6 | R7 made DNP for the export variant | B | 3 | no |
| 7 | J1 replaced — original EOL, different land pattern | C | 1 | yes |
| 8 | Firmware image version updated in the BOM | C | 2 | no |
| 9 | Conformal coating added to the build | C | 3 | no |
Sample data. Three PCB revisions, nine assembly revisions. Note that the assembly counter resets when the PCB revision changes — that is one convention among several, and it works because C-1 then unambiguously means "the first build of revision C".
The decision table
| Change | PCB rev | Asm rev |
|---|---|---|
| Copper routing changed | yes | yes |
| Footprint changed or replaced | yes | yes |
| Hole size or position changed | yes | yes |
| Board outline changed | yes | yes |
| Stackup changed | yes | yes |
| Silkscreen text corrected | yes — it is a layer | yes |
| Component value changed, same footprint | no | yes |
| Component manufacturer changed | no | yes |
| Part made DNP, or un-DNP'd | no | yes |
| Approved alternative added | no | yes |
| Quantity on a line changed | no | yes |
| Programmed firmware version changed | no | yes |
| Process change — coating, selective solder | no | yes |
| Typo fixed in a document, nothing physical | no | no |
The pattern: if the fabricator has to do something different, the PCB revision changes. If only the assembler does, only the assembly revision changes. That single question resolves almost every case.
Note the silkscreen row. It feels like documentation but it is a fabricated layer, so it needs new bare boards. Teams that treat silkscreen edits as "just text" end up with boards whose printed revision does not match their actual revision, which is worse than no marking at all.
The edge cases
A part changes to a different package. Different footprint, so the PCB revision changes even though "only a component changed". The land pattern is part of the board.
A footprint is corrected but the part is the same. PCB revision. The copper changed.
A DNP part becomes fitted. No PCB change — the footprint was already there. That was the point of leaving it.
The board is unchanged but built on a different panel. Neither revision changes. Panelisation is a manufacturing arrangement, not a design property, and it belongs in the fabrication notes.
You change the solder paste alloy. Assembly revision. Nothing about the design moved.
What has to be stated together
An assembly revision on its own identifies nothing. Rev 3 is meaningless without knowing which PCB revision it sits on.
So the pairing has to appear:
on the silkscreen, where there is room — at minimum the PCB revision; in the BOM header; in the assembly drawing; in the release note; * on the physical label, if the product has one.
A board marked only REV C tells you what the bare board is and nothing about what is fitted. That is usually enough for a fabricator and not enough for anyone diagnosing a field failure.
Where this commonly goes wrong
Everything is one number. Nine revisions, nine PCB orders, most of them unnecessary. Expensive and slow.
Nothing is versioned but the PCB. Four different builds all called Rev C, and a field failure that cannot be traced to a configuration.
The assembly counter does not reset, or resets inconsistently. C-7 following B-6 suggests a continuity that does not exist. Pick one rule.
Silkscreen revision not updated with the PCB revision. The board says B, the files say C. The physical marking is the one people trust, so this is actively dangerous.
No written rule. Two engineers make opposite calls on the same kind of change, six months apart, and the history stops meaning anything.
What to write down
One paragraph in your engineering notes is enough:
The PCB revision is a letter and changes whenever a fabrication output changes. The assembly revision is a number, resets with each PCB revision, and changes whenever what is fitted changes. Both appear in the BOM header and the release note; the PCB revision appears on the silkscreen.
That is the whole policy. The value is not in the specific choices — it is in there being a written rule that two people apply the same way.
Deciding which number moves is a judgement you can make from the table above. Keeping the two chains straight across years, so that a BOM revision is still attached to the PCB revision it was written for, is the part that needs somewhere durable to live.
In XKEMA the board and its bill of materials each carry their own version chain, and each version records which one came before it.
Hardware configuration management Hardware revision control: a practical guide * How to manage BOM revisions