Product version/revision assignment

[Mad ID]

Hi,
How do you assign version/revision marking to your designs / products?

Currently my company uses only versions. Let’s say we do a first prototype and name it Board V1. There are some hardware bugs and/or small changes and we have V2 already. On more difficult designs we end up with V4 with none or small functionality changes before the board even reached the field.

Since that doesn’t make sense, we decided to add revision marking. 
So in the upper case we would have V1,rev 1. I presume it is better to use letters for revision so they cannot mix up, i.e. V1, rev A.

I must add we also use part numbers, so the Board V1 has a part number associated with it's name.
What is the best practice in your opinion?

[fivefish]

My 2 cents.

I have the brand (company name), product name, and then Revision number on the PCB. I start with Rev.1.00 for my 1st prototype PCB. When I get the PCBs back and find I need to make *minor* corrections (component spacing adjustments, rerouting, fixing forgotten traces) and respin the board, it then goes out as Rev.1.1. More fixes... Rev1.2, etc...  and so on.  The PCB that finally goes to the customer may be a Rev1.2 or maybe even a Rev1.4!

Only when I make a radical change to the design (form factor, size, footprint, controls, etc) do I make a big jump and call it a Rev2.00. It may still have the same product name, or maybe a variation of the original product name + mark2 (i.e. THING-A-JIG mk2) and from there, PCB *minor* revisions do point upgrades Rev2.1, Rev2.2, etc. 

[ehughes]

1st you have to decide when you start tracking versions.  You mentioned that track your "Versions"  before it went into the field (i.e. V4) didn't make sense with the scheme.     

Here is a common way I versioning performed.   The 1st thing you have to do is establish a discipline for how version is tracked, independent of who see it.   You have to immediately throw away practices done in the software industry.

1.)   There are 2 concepts you have to consider.  A part (a single item you acquire from somewhere else) and an assembly (parts/assemblies you put together).
2.)  For hardware,   when does the version get applied?.  For example.   When a PCB is fabbed (I.E. you receive it hand),   whatever the state of the design files are, that is a version.       The most common method is a letter (A,B,C).
3.) When working on a PCB, if you do multiple edited along the way (but never fab the board),  it is common to track this with a commit number, or some other "dot number" etc.   When the board is actually sent for fab,  it is tagged with a version letter.
4.)   All parts and assemblies have a "number".     The only time part numbers are shared is if you can put the same items in the same bin for assembly.

At this point you now have to consider your build tree.     For example:

Let's say you have 1 PCB that is put in a box with 4 screws.    In the simplest case you have 5 part numbers.

The Raw PCB            (Part Number 0001) Rev A
The assembled PCB with parts (Assembly Number 0002) Rev A
The 4 Screws (Each screw is part number 0003) Rev A
The Box (Part number 0004) Rev A
The Finished Product (Assembly Number 0005) Rev A.   Is is comprised of 0002 (which is 0001 + all the part numbers) 0003 and 0004


If you go to Rev B of the board,   Everything higher on the tree must also be versioned up.  The assembled board and finished Product go to Rev B. 

If you have a firmware load,  it is part of the circuit card assembly, which gets it's own version!

This is pretty common with "physical" stuff.  As you can see, there are lots of shades of grey in between.  It all comes down to how much traceability you need.      Large complex designs often use some PLM tool....    (i.e. lots of money, consultants and contracts!)


Good Luck.

[Dago]

I have personally been using a system where I also have a version number and a revision number. Version is related to functionality and revision to PCB. Meaning if there are larger changes in the project (like new added features or different MCU or something) then the version number changes. If there are just small bug fixes or other small changes to the PCB then the revision number changes. The revision number is also used for making a distinction between different sets of gerbers with the factory. So I send project_v1_rev1.zip to the factory, they might ask for some small changes and the fixed zip I'd send would be project_v1_rev2.zip. Otherwise they might mess up at the factory and use older/wrong gerbers so it is good to have a new name/version/revision for them.

[AndyC_772]

I've yet to see a system that works really well from the perspectives of everyone involved. The big problem is there's a trade-off between traceability and manageability, and you very soon end up needing a fully automated system to keep track of all the revisions (or possibly an intern who has an exceptional eye for detail but at the same time doesn't get bored easily).

For a PCB, I might typically assign a revision letter to each board revision that gets fabricated, so the first PCB that arrives will be rev A.

Then, there's a number assigned to each revision of the BoM, which gets incremented each time there's a component change.

So, the first board to arrive from a manufacturer is likely to be revision A1. This board spends some time in the lab, a few component value changes are made, and the first units to be demonstrated might be up to revision A3. There's also likely to be some wire mods, so there will be a separate mod requirements document which explains what the mods are, which board or BoM revisions they apply to, and why they're needed.

It may then make sense to up-issue the PCB, so the PCB becomes rev B, and the associated BoM becomes rev B1 even if there are actually no material changes to the BoM from rev A3. The first letter of the BoM revision is simply the PCB revision to which it applies.

This all works fine until you have a more complex hierarchy of BoMs, including mechanical assemblies, firmware, option codes, included accessories and the like. Then it rapidly becomes a nightmare, as every change requires a corresponding change to the next level up... unless you work on the principle that the "latest" version of any part is always the one to use. That avoids the ripple effect, where changing a resistor value results in a dozen other BoMs having to change just to reference the update, but it means you lose traceability.

[KL27x]

I have always used v/version for firmware and rev/revision for PCB/hardware. (I track and/or selectively compile the rev variant of the firmware within the code history and/or code, itself).

I presume it is better to use letters for revision so they cannot mix up, i.e. V1, rev A.

W/e floats your boat. I don't understand what your distinction is between revision and version, in this context. Rather than v1 revA, why not just call it v1A or rev1A? Or v1.001, if you like. Unless you are concurrently making different variations of the same board to suit different applications?

[Warhawk]

Some time ago I was thinking about the same thing. Then I started using the following marking:

vX.Y rev Z

example:
v1.0 rev A

key:
X - major change or a new functionality
Y - change in a BOM or netlist, no new functionality
Z - change in PCB design only (e.g. moving connector etc.).