7

I have one hardware design developed for a customer. We are also selling the same for some more customers with small modifications

I would like to know how to provide version numbers for these different customers; is there any standard defined for hardware design versioning?

e.g. In software people do the versions as V 1.0.1; V 1.2.2; V 3.0.0

I would like to is it useful for hardware also? How?

I would like to maintain hardware revision documents in company system database as a reference for others. Idea is, just by looking at version number other engineer can quickly identify differences with respect to revision document.

Akky
  • 209
  • 3
  • 10
  • I would add square boxes on the silkscreen which you can 'tick' with a waterproof felt-pen. – Oldfart Nov 13 '18 at 11:55
  • 1
    I've also seen pullup/pulldown resistors used to give a machine-readable revision number, if you have a few spare pins on your microcontroller. – Hearth Nov 13 '18 at 12:34
  • This Q or similar comes up reasonably often, some ideas here: https://electronics.stackexchange.com/questions/371696/encoding-version-or-configuration-on-pcb – awjlogan Nov 13 '18 at 13:26
  • Boards usually have a fab number etched in copper, and an assembly number on the silkscreen layer. Fab revision is for updated versions of the same PCB artwork (gerbers). The revison block of the assembly number is usually left blank so you can write in the appropriate revision. Or use a sticker. If you have a modified version of the PCB for a different customer, the standard practice would be to use a completely different FAB and assembly number. Not a revision code. – user57037 Nov 15 '18 at 07:42

3 Answers3

4

We handle it the following way: Major.Minor.Revision

Major is changed, if there were changes to board dimensions or extensive changes to component placement or general functionality. Like re-designing a PCB for a different enclosure or adding a new connector.

Minor is changed, if there were any changes to component placement, routing, copper fills etc. Essentially any change, that potentially changes electrical characteristics.

Revision represents the revision number from our version control system (Subversion) and thus increases with every committed change. This could be a small change to the silkscreen or changing component types/values due to better availability. Versions with a revision changes only can be processed by the assembly house without any adjustments (paste mask compatible, same dimensions, same pick&place).

Version progression: If Major is incremented, Minor resets to 0. Revisions always increments and unambiguously identifies a specific version. Example: 1.0.0 -> 1.0.1 -> 1.0.2 -> 1.1.3 -> 2.0.4

Relevance to part list: Our BOM contains a reference to the Major.Minor version of the compatible target PCB. The revision is not relevant with respect to the PCB, since there were no relevant physical changes. Thus, 1.2.10 can be assembled just like 1.2.15. The BOM itself has a revision number, that is equal or higher than the target PCB version. Example: A BOM titled "BOM 1.2.18 - Target PCB 1.2" can be used to assemble boards of version 1.2.10 as well as 1.2.15.

Rev
  • 10,017
  • 7
  • 40
  • 77
3

In one of the companies in which I worked, we descript the project, for example: 1801p1v1r1.

18 - is the year the project was founded (here 2018)

01 - another project in a given year

p1 - project first

v1 - first version

r1 - revision first

When I create the first scheme and BOM, I describe them: 1801p1v1r1. The PCB design and PCB board describe 1801p1v1 (no revision).

And now the meaning of these signs: Let's assume that we have a finish scheme, ordered PCBs, we have made tests and we have to make changes. If, for example, we need to replace the 1k resistor in the 0603 housing with the 1.2k 0603 resistor, then we will only change the revision:

Scheme: 1801p1v1r2

BOM: 1801p1v1r2

PCB: 1801p1v1

Therefore, there is no need for revision marks on the PCB, because the PCB itself does not change in this case. We only change the values ​​in the diagram and in the BOM. We can also have different value on schematic for one PCB.

If we have to change eg a resistor from housing 0603 to 1206, then we have to change the version:

Scheme: 1801p1v2r1

BOM: 1801p1v2r1

PCB: 1801p1v2

However, if we have a project consisting of 2 PCBs to design, then we have to mark one as project 1 and the other as project 2:

Project 1 describes:

Scheme: 1801p1v1r1

BOM: 1801p1v1r1

PCB: 1801p1v1

Project 2 descirbes:

Scheme: 1801p2v1r1

BOM: 1801p2v1r1

PCB: 1801p2v1

It may seem complicated in the description, but in practice it is a ease and logical.

I described it in more detail on my blog: http://sigaris-electronics.eu/2019/01/my-way-of-naming-electronic-projects/

sigaris
  • 185
  • 1
  • 2
  • 8
2

I'm just going to put something here about the semantics of version numbering.

You can number things Major.Minor.Build.Revision as if you were programming something and apply them to their parallel task in physical design.

Revision numbers separate your files previous to manufacture as you make each initial modification in design stage

Build numbers would be versions that made it to manufacturing, including small sets of revisions like a material or minor dimensional change.

Minor numbers would be for manufacturing reworks previous to the new version, such as a modification to improve efficiency or meet a safety requirement.

Major build number would be typically the yearly reworking of the product

You can also use a convention for branching like ABC are for equivalent branches, like a product with an A B and C version that are equivalent but equipped differently, like a drill, angle grinder and circular saw with the same battery, motor and control mechanism.

Really it can be anything you like but if you want it to work across a company with multiple developers it has to be easy to remember and execute.

K H
  • 4,023
  • 1
  • 11
  • 24