Re: PCB version control

On Wed, 26 Mar 2025 11:49:15 -0700, john larkin <jl@glen--canyon.com>
wrote:

On Tue, 25 Mar 2025 23:28:01 -0700, Don Y
<blockedofcourse@foo.invalid> wrote:
>

On 3/25/2025 3:53 AM, Don Y wrote:

On 3/25/2025 3:44 AM, Don Y wrote:

   "No.  I can replace a single page if necessary.  So, each EPROM
   /in the set/ can be at a different revision level.  It's up to
   Engineering to manage this (configuration management) so only
   valid "combinations" of those devices are incorporated into a
   released product."

 
This last is important.  If you want to force a production change,
you have to change a part number, not a revision level.
 
E.g., I can revise an algorithm in a particular piece of code.
Any revision will perform identically (if performance is
defined by getting the correct "result"/return value).  A new
revision may change some other aspect -- a faster algorithm,
smaller, better documented, etc. -- but is same fit/form/function
as the earlier revision.
 
If I *need* the product to use a newer version of that algorithm,
then I have to give the function a new part number and update the
BoM (makefile) to reflect that new part number.

>
To drive this home:
<https://www.product-lifecycle-management.com/plm-best-practice-revision.htm>
<https://cdn2.hubspot.net/hubfs/2568500/Content%20Offer%20PDFs/MCL_Revision_vs_New_Part_Number_Infographic.pdf>

>
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.

Form, Fit, and Function is now widely applied:

.<https://en.wikipedia.org/wiki/Form,_fit_and_function>

Joe

>

<https://plmadvisors.com/plm-and-configuration-management-best-practices-part-numbers/>
>
Assuming you have assigned part numbers to each software module/file,
consider how you currently think of "version control".  Is a rev B
version of that file INTERCHANGEABLE with a rev A version (see above
criteria)?  Likely the new file would have an augmented set of
test cases to reflect the fact that it is now tested against the
condition(s) that the earlier version was found to be defective!
>
[So, *two* documents need to change before this is propagated]
>
Chances are, it is not!  Rev B likely came about to FIX something
that was broken in rev A.  So, using rev B in place of rev A would
lead to a different product (one that is more correct than the
predecessor).
>
As such, the part number for that file should change to reflect this
incompatibility.  This change would then propagate upward through the
assemblies to eventually reflect the fact that the finished product
with the "revised file" is, in fact, a different and not interchangeable
product with those that were built on the unrevised file.

>
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.
>

>
You surely wouldn't build a copy of last year's code base and try to
pawn it off as identical with the most recent codebase!

>
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.