PCB version control

For a V375 VME module, our schematic drawing number is 22S375A, where

22D375A is the PCB fab (drill) drawing and pcb design file name.

22M37501B might be a mechanical part drawing, like a front panel.

During development, we iterate the schematic and PCB together, as

We have a formal procedure about all this. FPGAs, uP code, test sets and procedures and software have to be coordinated too.

Times hundreds of products with rev letters and dash number versions, this gets serious.

Prototypes are 99 series, with informal project files on a server. These are essentially little breadboards. We don't prototype entire products; we just release the full rev A document set to manufacturing and expect it to work.

I see, that makes sense. Some designs I'm working on now are modest enough that can do that with the entire product relatively cheaply, so I guess, y'know, existentially speaking, if "A" ended up needing major revisions, but _if_ it had worked first time it could've been sell-able, that should count that as a letter-revision.

That is to say I guess it makes sense to be consistent and give any full board that gets manufactured in whatever quantity a letter revision, and I like the idea of giving "little breadboards" that aren't a full thing their own project/test series designation

We roll the rev letter if there is any change to the schematic or the PCB. Dash numbers identify versions, like parts values or stuffing options. A new BOM can create a dash number without revving the PCB.

This is a quasi-military drawing number system which is in fact acceptable to the US military and NASA.

It's important to note that only physical things have dash numbers. Drawings don't.

We have one big customer that assigns the next available 12-digit number (their 12NC) to the next thing that needs a number. A schematic, a forklift, a building, an employee. You need a cross-reference to tell which schematic corresponds to which PCB.

Do you propose to assign a random number to any drawing or any part or any variant of any physical assembly?

Do you propose to not have revision letters or dash numbers?

Far from unknown. It does introduce a critical dependency on some database. (Windchill is a popular choice, or was a decade ago when I last looked. )

I’m with you—it’s good for stuff to be human-manageable.

Cheers

Phil Hobbs

The airplane boys used a drawing number and a rev letter and a dash number to define a part, like an airplane wing. The convention was that xxxxx-1 was a physical part defined by drawing xxxxx, and xxxxx-2 was its mirror image. -1 was the left wing, I think.

We don't do that, but we assume that drawing 22A123A defines part

Military and aerospace folks usually require that any physical part have the full part number (with rev letter and dash number) engraved on the part itself.

Windchill is still going strong.

With very large companies, the drawing numbers might as well be random, and no coding scheme can survive.

Below some size, this can be done.

I've run into problems trying to code the sub-fields of small addresses (used within some hardware gadget). It took only two or three implementations of such gadgets before one ran out of code space. The solution was to make each kind of gadget have its own subfield coding, because these devices were bespoke anyway.

Joe

Our stocked parts are identified by a 7-digit MAX number, like

The MAX numbers appear on the BOM associated with an assembly drawing.

MAX is our material control software.

We often qualify several different manufacturers and their (often weird) part numbers for a given MAX part. And sometimes we change them, but we don't want to change our BOMs. Lots of manufacturing control software doesn't understand that concept, having multiple vendors qualified for one part.

Full Traceability is a different ballgame. We don't do that.

If it's functionally different but runs on the same hardware, the assembly becomes a new dash number. The BOM for the new dash number variant calls out the new firmware. If the hardware didn't change, its rev letter doesn't change if we change the code that runs on it.

If one line of code changes, the software rev letter rolls. We treat software just like any other drawing; it has a drawing number and a rev letter.

Some software naming schemes are nightmares. Version 14.571.03b and such.

How about a bidirectional hash table for part # generation

We have such a scheme. All 0805 resistors are 132-xxxx, where xxxx encodes the value and allows for variants. The algorithm is documented.

We have over 8000 different parts in stock and 10 million available part numbers. It works fine.

And, another digit to indicate package and lead orientation,

A program with a document number, called out in the product BOM.

That works fine too.

Read the BOM.

People build airplanes, dams, all sorts of things without difficulty.

OK so...how should I do revisions of this PCB/product (the product is the PCB) again? It has a board, and uP code, and FPGA code. Can you provide a motivational example

Apparently HP had it right when every product was just like some meaningless number followed by a revision letter, eh?

I think I'm just gonna use manufacturer PNs for externally-sourced parts; having to consult a table to find out PN 4917485 is just like a bloody 10k 0402 resistor sounds like bullshit to me.

If we used a mpn on a BOM, how would we handle alternate vendors?

When you see an mpn on your BOM, how do you know what it is? Google it? It ain't always obvious. It turns out that there are many different things with manufacturers part number "54"

We have 1800 BOMs. I wouldn't want to edit 600 of them if I switch from Panasonic to Murata for a bypass cap.

We don't consult a table, we just run our MAX program. I can type in a stock number, a description, or a mfr part number. I can see where any part is used. Many parts have associated folders with data sheets, notes, pictures.

I can do a search for res++0805++4.99K and see what we have in stock. Anybody serious, that has hundreds of parts that they use, needs a system like this. We have over 8000.

If we outsource, we would absolutely require that the parts be exactly what we have qualified. We often qualify several mfrs and mpns for a given stock number.

We don't want cheap, maybe counterfeit parts, in our products.

I do have a database of parts I have on hand, mainly for my own sanity when finding parts to prototype something with. I outgrew the organizational limits of just writing categories on drawers in Sharpie a while back, I have too many distinct parts.

But I don't always keep stock on hand of every part that's in a design though, like you I don't breadboard whole designs. A recent design has a

My personal parts stock is stashed in little brown coin envelopes. The company stock is a couple thousand square feet of shelving.

We engineers are officially not allowed into the stock room. We email a parts request if we want a few of something. Or order from Amazon.

Once a customer orders a Q451, they will expect to be able to order more Q451's. And we advertise the virtues of Q151's. So even if we add an LED or a software feature, we want to still call it a Q151, and roll the rev letter internally.

The FFF thing is more a military requirement. Or a requirement from people like Intel with a copy-exact philisophy.

Compatibility of hardware and software is controlled by the BOM for this specific product/rev/dash number. The BOM has comments when that would help.

We don't revise released software. That would be a nightmare.

Last years code was compiled and released and archived, with a drawing number and a rev letter. Any changes would be a new rev letter with a new release package. Why treat software any different than hardware?

On the internet, people can and do push out buggy code releases often. On an electronic instrument, it's not a good idea to do that.

Form, Fit, and Function is now widely applied:

.

Joe

A real example, that caused some pain, was the Raspberry Pi 3B+, which at some point changed internally from rev. 1.3 to rev 1.4. Unfortunately this was not made visible on purchase ("It's an RPi

So, should they have sold the rev. 1.4 3B+ as something different (3.1B+)?

No idea what changed, but it must have been significant enough to require a change to the bootloader. I assume (hope) it was a necessary change, i.e. it wasn't possible to make any more rev.